Select Git revision
Search by author
- Any Author
- authors
-
Alessandro Pecugi alessandro.pecugi
-
Andrea Da Col
andrea.dacol
-
Andrii Sosiuk
andrii.sosiuk
-
Carlo Ferriolo carlo.ferriolo
-
Christian Stimming
christian.stimming
-
Christos Karampeazis
-
CI Variables Management Service Account service_account_ci_vars_management
-
Costanza Vasai costanza.vasai
-
Daniel Rinaldi daniel.rinaldi
-
Davide Cardillo
davide.cardillo
-
Dietmar Muscholik dietmar.muscholik
-
Dmitry Petrov dmitry.petrov
-
Elias Radi elias.radi
-
Ettore Chimenti
ektor5
-
Fabio Falsini
fabio.falsini
-
Fabrizio Benvenuti fabrizio.benvenuti
-
Felix Gerking felix.gerking
-
Gianfranco Mariotti
gianfranco.mariotti
-
GitBot
gitbot
-
Git Bot Service Account
service_account_gitbot
- May 14, 2021
-
-
Athira Rajeev authored
[ Upstream commit 10f8f961 ] The power PMU group constraints includes check for EBB events to make sure all events in a group must agree on EBB. This will prevent scheduling EBB and non-EBB events together. But in the existing check, settings for constraint mask and value is interchanged. Patch fixes the same. Before the patch, PMU selftest "cpu_event_pinned_vs_ebb_test" fails with below in dmesg logs. This happens because EBB event gets enabled along with a non-EBB cpu event. [35600.453346] cpu_event_pinne[41326]: illegal instruction (4) at 10004a18 nip 10004a18 lr 100049f8 code 1 in cpu_event_pinned_vs_ebb_test[10000000+10000] Test results after the patch: $ ./pmu/ebb/cpu_event_pinned_vs_ebb_test test: cpu_event_pinned_vs_ebb tags: git_version:v5.12-rc5-93-gf28c3125acd3-dirty Binding to cpu 8 EBB Handler is at 0x100050c8 read error on event 0x7fffe6bd4040! PM_RUN_INST_CMPL: result 9872 running/enabled 37930432 success: cpu_event_pinned_vs_ebb This bug was hidden by other logic until commit 1908dc91 (perf: Tweak perf_event_attr::exclusive semantics). Fixes: 4df48999 ("powerpc/perf: Add power8 EBB support") Reported-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> [mpe: Mention commit 1908dc91] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1617725761-1464-1-git-send-email-atrajeev@linux.vnet.ibm.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jordan Niethe authored
[ Upstream commit b8b2f37c ] When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults. As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/ Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify [<c000000000bf8e5c>] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call Trace: ftrace_bug+0x288/0x2e8 (unreliable) ftrace_modify_all_code+0x168/0x210 arch_ftrace_update_code+0x18/0x30 ftrace_run_update_code+0x44/0xc0 ftrace_startup+0xf8/0x1c0 register_ftrace_function+0x4c/0xc0 function_trace_init+0x80/0xb0 tracing_set_tracer+0x2a4/0x4f0 tracing_set_trace_write+0xd4/0x130 vfs_write+0xf0/0x330 ksys_write+0x84/0x140 system_call_exception+0x14c/0x230 system_call_common+0xf0/0x27c To fix this when updating kernel memory PTEs using ptesync. Fixes: f1cb8f9b ("powerpc/64s/radix: avoid ptesync after set_pte and ptep_set_access_flags") Signed-off-by:
Jordan Niethe <jniethe5@gmail.com> Reviewed-by:
Nicholas Piggin <npiggin@gmail.com> [mpe: Tidy up change log slightly] Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit ca5f7256 ] The code currently assumes that the mmu_notifier struct embedded in mmu_rb_handler only contains two fields. There are now extra fields: struct mmu_notifier { struct hlist_node hlist; const struct mmu_notifier_ops *ops; struct mm_struct *mm; struct rcu_head rcu; unsigned int users; }; Given that there in no init for the mmu_notifier, a kzalloc() should be used to insure that any newly added fields are given a predictable initial value of zero. Fixes: 06e0ffa6 ("IB/hfi1: Re-factor MMU notification code") Link: https://lore.kernel.org/r/1617026056-50483-9-git-send-email-dennis.dalessandro@cornelisnetworks.com Reviewed-by:
Adam Goldman <adam.goldman@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 298b58f0 ] The macro CN23XX_PEM_BAR1_INDEX_REG is being used to shift oct->pcie_port (a u16) left 24 places. There are two subtle issues here, first the shift gets promoted to an signed int and then sign extended to a u64. If oct->pcie_port is 0x80 or more then the upper bits get sign extended to 1. Secondly shfiting a u16 24 bits will lead to an overflow so it needs to be cast to a u64 for all the bits to not overflow. It is entirely possible that the u16 port value is never large enough for this to fail, but it is useful to fix unintended overflows such as this. Fix this by casting the port parameter to the macro to a u64 before the shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 5bc67f58 ("liquidio: CN23XX register definitions") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit fa74c223 ] The 'single_cpu' local variable is assigned by asoc_simple_parse_dai() and later used in a asoc_simple_canonicalize_cpu() call, assuming the entire function did not exit on errors. However the first function returns 0 if passed device_node is NULL, thus leaving the variable uninitialized and reporting success. Addresses-Coverity: Uninitialized scalar variable Fixes: 8f7f298a ("ASoC: simple-card-utils: separate asoc_simple_card_parse_dai()") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by:
Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/20210407092027.60769-1-krzysztof.kozlowski@canonical.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Alexandru Elisei authored
[ Upstream commit 263d6287 ] When a VCPU is created, the kvm_vcpu struct is initialized to zero in kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is set to a sensible value in kvm_arm_setup_debug() later in the run loop. The result is that KVM executes for a short time with MDCR_EL2 set to zero. This has several unintended consequences: * Setting MDCR_EL2.HPMN to 0 is constrained unpredictable according to ARM DDI 0487G.a, page D13-3820. The behavior specified by the architecture in this case is for the PE to behave as if MDCR_EL2.HPMN is set to a value less than or equal to PMCR_EL0.N, which means that an unknown number of counters are now disabled by MDCR_EL2.HPME, which is zero. * The host configuration for the other debug features controlled by MDCR_EL2 is temporarily lost. This has been harmless so far, as Linux doesn't use the other fields, but that might change in the future. Let's avoid both issues by initializing the VCPU's mdcr_el2 field in kvm_vcpu_vcpu_first_run_init(), thus making sure that the MDCR_EL2 register has a consistent value after each vcpu_load(). Fixes: d5a21bcc ("KVM: arm64: Move common VHE/non-VHE trap config in separate functions") Signed-off-by:
Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210407144857.199746-3-alexandru.elisei@arm.com Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 61710324 ] Mapping the mic-mute button to KEY_MICMUTE is technically correct but KEY_MICMUTE translates to a scancode of 256 (248 + 8) under X, which does not fit in 8 bits, so it does not work. Because of this userspace is expecting KEY_F20 instead, theoretically KEY_MICMUTE should work under Wayland but even there it does not work, because the desktop-environment is listening only for KEY_F20 and not for KEY_MICMUTE. Fixes: bc04b37e ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 34348a86 ] The HID lenovo probe function only attaches drvdata to one of the USB interfaces, but lenovo_event() will get called for all USB interfaces to which hid-lenovo is bound. This allows a malicious device to fake being a device handled by hid-lenovo, which generates events for which lenovo_event() has special handling (and thus dereferences hid_get_drvdata()) on another interface triggering a NULL pointer exception. Add a check for hid_get_drvdata() returning NULL, avoiding this possible NULL pointer exception. Fixes: bc04b37e ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by:
-
Hans de Goede authored
[ Upstream commit 658d04e6 ] Fix the following issues with lenovo_led_set_tp10ubkbd() error handling: 1. On success hid_hw_raw_request() returns the number of bytes sent. So we should check for (ret != 3) rather then for (ret != 0). 2. Actually propagate errors to the caller. 3. Since the LEDs are part of an USB keyboard-dock the mute LEDs can go away at any time. Don't log an error when ret == -ENODEV and set the LED_HW_PLUGGABLE flag to avoid errors getting logged when the USB gets disconnected. Fixes: bc04b37e ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by:
-
Hans de Goede authored
[ Upstream commit bbf62645 ] The lenovo_led_brightness_set function may sleep, so we should have the the led_class_dev's brightness_set_blocking callback point to it, rather then the regular brightness_set callback. When toggled through sysfs this is not a problem, but the brightness_set callback may be called from atomic context when using LED-triggers. Fixes: bc04b37e ("HID: lenovo: Add ThinkPad 10 Ultrabook Keyboard support") Reviewed-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 5fb45414 ] There are a few calls of usb_driver_claim_interface() but all of those miss the proper error checks, as reported by Coverity. This patch adds those missing checks. Along with it, replace the magic pointer with -1 with a constant USB_AUDIO_IFACE_UNUSED for better readability. Reported-by:
coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1475943 ("Error handling issues") Addresses-Coverity-ID: 1475944 ("Error handling issues") Addresses-Coverity-ID: 1475945 ("Error handling issues") Fixes: b1ce7ba6 ("ALSA: usb-audio: claim autodetected PCM interfaces all at once") Fixes: e5779998 ("ALSA: usb-audio: refactor code") Link: https://lore.kernel.org/r/202104051059.FB7F3016@keescook Link: https://lore.kernel.org/r/20210406113534.30455-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Lu Baolu authored
[ Upstream commit c0474a60 ] When the Intel IOMMU is operating in the scalable mode, some information from the root and context table may be used to tag entries in the PASID cache. Software should invalidate the PASID-cache when changing root or context table entries. Suggested-by:
Ashok Raj <ashok.raj@intel.com> Fixes: 7373a8cc ("iommu/vt-d: Setup context and enable RID2PASID support") Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20210320025415.641201-4-baolu.lu@linux.intel.com Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Lu Baolu authored
[ Upstream commit eea53c58 ] When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. Suggested-by:
-
Lu Baolu authored
[ Upstream commit a8ce9ebb ] The Access/Dirty bits in the first level page table entry will be set whenever a page table entry was used for address translation or write permission was successfully translated. This is always true when using the first-level page table for kernel IOVA. Instead of wasting hardware cycles to update the certain bits, it's better to set them up at the beginning. Suggested-by:
-
Lu Baolu authored
[ Upstream commit 03d20509 ] The Address field of the Page Request Descriptor only keeps bit [63:12] of the offending address. Convert it to a full address before reporting it to device drivers. Fixes: eb8d93ea ("iommu/vt-d: Report page request faults for guest SVA") Signed-off-by:
-
Lu Baolu authored
[ Upstream commit 6c00612d ] The Intel VT-d driver checks wrong register to report snoop capablility when using first level page table for GPA to HPA translation. This might lead the IOMMU driver to say that it supports snooping control, but in reality, it does not. Fix this by always setting PASID-table-entry.PGSNP whenever a pasid entry is setting up for GPA to HPA translation so that the IOMMU driver could report snoop capability as long as it runs in the scalable mode. Fixes: b802d070 ("iommu/vt-d: Use iova over first level") Suggested-by:
Rajesh Sankaran <rajesh.sankaran@intel.com> Suggested-by:
Kevin Tian <kevin.tian@intel.com> Suggested-by:
-
Xiang Chen authored
[ Upstream commit 3431c3f6 ] After the change of patch ("iommu: Switch gather->end to the inclusive end"), the performace drops from 1600+K IOPS to 1200K in our kunpeng ARM64 platform. We find that the range [start1, end1) actually is joint from the range [end1, end2), but it is considered as disjoint after the change, so it needs more times of TLB sync, and spends more time on it. So fix the boundary issue to avoid performance drop. Fixes: 862c3715 ("iommu: Switch gather->end to the inclusive end") Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Acked-by:
Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/1616643504-120688-1-git-send-email-chenxiang66@hisilicon.com Signed-off-by:
-
Lu Baolu authored
[ Upstream commit 1d421058 ] The VT-d specification (section 7.6) requires that the value in the Private Data field of a Page Group Response Descriptor must match the value in the Private Data field of the respective Page Request Descriptor. The private data field of a page group response descriptor is set then immediately cleared in prq_event_thread(). This breaks the rule defined by the VT-d specification. Fix it by moving clearing code up. Fixes: 5b438f4b ("iommu/vt-d: Support page request in scalable mode") Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Reviewed-by:
Liu Yi L <yi.l.liu@intel.com> Signed-off-by:
-
Álvaro Fernández Rojas authored
[ Upstream commit cde58b86 ] Commit a23c4134 added the clock controller nodes, incorrectly changing the syscon-reboot nodes addresses. Fixes: a23c4134 ("MIPS: BMIPS: add clock controller nodes") Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
-
Salil Mehta authored
[ Upstream commit d392ecd1 ] Limiting the scope of the variable vector_ring_chain to the block where it is used. Fixes: 424eb834 ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC") Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit ca4d4c34 ] If the "type_a->nfcid_len" is too large then it would lead to memory corruption in pn533_target_found_type_a() when we do: memcpy(nfc_tgt->nfcid1, tgt_type_a->nfcid_data, nfc_tgt->nfcid1_len); Fixes: c3b1e1e8 ("NFC: Export NFCID1 from pn533") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Håkon Bugge authored
[ Upstream commit 194f64a3 ] On RoCE systems, a CM REQ contains a Primary Hop Limit > 1 and Primary Subnet Local is zero. In cm_req_handler(), the cm_process_routed_req() function is called. Since the Primary Subnet Local value is zero in the request, and since this is RoCE (Primary Local LID is permissive), the following statement will be executed: IBA_SET(CM_REQ_PRIMARY_SL, req_msg, wc->sl); This corrupts SL in req_msg if it was different from zero. In other words, a request to setup a connection using an SL != zero, will not be honored, and a connection using SL zero will be created instead. Fixed by not calling cm_process_routed_req() on RoCE systems, the cm_process_route_req() is only for IB anyhow. Fixes: 3971c9f6 ("IB/cm: Add interim support for routed paths") Link: https://lore.kernel.org/r/1616420132-31005-1-git-send-email-haakon.bugge@oracle.com Signed-off-by:
Håkon Bugge <haakon.bugge@oracle.com> Signed-off-by:
-
Andrew Scull authored
[ Upstream commit 3ad1a6cb ] report_bug() will return early if it cannot find a bug corresponding to the provided address. The subsequent test for the bug will always be true so remove it. Fixes: 1b4cfe3c ("lib/bug.c: exclude non-BUG/WARN exceptions from report_bug()") Signed-off-by:
Andrew Scull <ascull@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org> Reviewed-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Acked-by:
-
Yang Yingliang authored
[ Upstream commit ac1db7ac ] Add the missing destroy_workqueue() before return from tipc_crypto_start() in the error handling case. Fixes: 1ef6f7c9 ("tipc: add automatic session key exchange") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Michael Ellerman authored
[ Upstream commit 11d92156 ] The vio bus is a fake bus, which we use on pseries LPARs (guests) to discover devices provided by the hypervisor. There's no need or sense in creating the vio bus on bare metal systems. Which is why commit 4336b933 ("powerpc/pseries: Make vio and ibmebus initcalls pseries specific") made the initialisation of the vio bus only happen in LPARs. However as a result of that commit we now see errors at boot on bare metal systems: Driver 'hvc_console' was unable to register with bus_type 'vio' because the bus was not initialized. Driver 'tpm_ibmvtpm' was unable to register with bus_type 'vio' because the bus was not initialized. This happens because those drivers are built-in, and are calling vio_register_driver(). It in turn calls driver_register() with a reference to vio_bus_type, but we haven't registered vio_bus_type with the driver core. Fix it by also guarding vio_register_driver() with a check to see if we are on pseries. Fixes: 4336b933 ("powerpc/pseries: Make vio and ibmebus initcalls pseries specific") Reported-by:
Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Link: https://lore.kernel.org/r/20210316010938.525657-1-mpe@ellerman.id.au Signed-off-by:
-
Paolo Abeni authored
[ Upstream commit 78352f73 ] Currently the UDP protocol delivers GSO_FRAGLIST packets to the sockets without the expected segmentation. This change addresses the issue introducing and maintaining a couple of new fields to explicitly accept SKB_GSO_UDP_L4 or GSO_FRAGLIST packets. Additionally updates udp_unexpected_gso() accordingly. UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist zeroed. v1 -> v2: - use 2 bits instead of a whole GSO bitmask (Willem) Fixes: 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Andre Edich authored
[ Upstream commit fdb5cc6a ] The function lan87xx_config_aneg_ext was introduced to configure LAN95xxA but as well writes to undocumented register of LAN87xx. This fix prevents that access. The function lan87xx_config_aneg_ext gets more suitable for the new behavior name. Reported-by:
Måns Rullgård <mans@mansr.com> Fixes: 05b35e7e ("smsc95xx: add phylib support") Signed-off-by:
Andre Edich <andre.edich@microchip.com> Signed-off-by:
-
Jia Zhou authored
[ Upstream commit abc21649 ] modification in commit 2a3f7221 ("ALSA: core: Fix card races between register and disconnect") resulting in this problem. Fixes: 2a3f7221 ("ALSA: core: Fix card races between register and disconnect") Signed-off-by:
Jia Zhou <zhou.jia2@zte.com.cn> Signed-off-by:
Yi Wang <wang.yi59@zte.com.cn> Link: https://lore.kernel.org/r/1616989007-34429-1-git-send-email-wang.yi59@zte.com.cn Signed-off-by:
-
Álvaro Fernández Rojas authored
[ Upstream commit 9c7d2469 ] The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in a compilation error when trying to build gpio-regmap if CONFIG_GPIOLIB_IRQCHIP isn't enabled. Fixes: 6a45b0e2 ("gpiolib: Introduce gpiochip_irqchip_add_domain()") Suggested-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20210324081923.20379-2-noltari@gmail.com Signed-off-by:
-
Tiezhu Yang authored
[ Upstream commit 66633abd ] After commit 0ebeea8c ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work"), bpf_probe_read{, str}() functions were no longer available on MIPS, so there exist some errors when running bpf program: root@linux:/home/loongson/bcc# python examples/tracing/task_switch.py bpf: Failed to load program: Invalid argument [...] 11: (85) call bpf_probe_read#4 unknown func bpf_probe_read#4 [...] Exception: Failed to load BPF program count_sched: Invalid argument ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE should be restricted to archs with non-overlapping address ranges, but they can overlap in EVA mode on MIPS, so select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE if !EVA in arch/mips/Kconfig, otherwise the bpf old helper bpf_probe_read() will not be available. This is similar with the commit d195b1d1 ("powerpc/bpf: Enable bpf_probe_read{, str}() on powerpc again"). Fixes: 0ebeea8c ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work") Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
-
Chen Huang authored
[ Upstream commit 4fe52944 ] When compiling the powerpc with the SMP disabled, it shows the issue: arch/powerpc/kernel/watchdog.c: In function ‘watchdog_smp_panic’: arch/powerpc/kernel/watchdog.c:177:4: error: implicit declaration of function ‘smp_send_nmi_ipi’; did you mean ‘smp_send_stop’? [-Werror=implicit-function-declaration] 177 | smp_send_nmi_ipi(c, wd_lockup_ipi, 1000000); | ^~~~~~~~~~~~~~~~ | smp_send_stop cc1: all warnings being treated as errors make[2]: *** [scripts/Makefile.build:273: arch/powerpc/kernel/watchdog.o] Error 1 make[1]: *** [scripts/Makefile.build:534: arch/powerpc/kernel] Error 2 make: *** [Makefile:1980: arch/powerpc] Error 2 make: *** Waiting for unfinished jobs.... We found that powerpc used ipi to implement hardlockup watchdog, so the HAVE_HARDLOCKUP_DETECTOR_ARCH should depend on the SMP. Fixes: 2104180a ("powerpc/64s: implement arch-specific hardlockup watchdog") Reported-by:
Chen Huang <chenhuang5@huawei.com> Signed-off-by:
-
Lv Yunlong authored
[ Upstream commit adb76a52 ] The device is got by isert_device_get() with refcount is 1, and is assigned to isert_conn by isert_conn->device = device. When isert_create_qp() failed, device will be freed with isert_device_put(). Later, the device is used in isert_free_login_buf(isert_conn) by the isert_conn->device->ib_device statement. Free the device in the correct order. Fixes: ae9ea9ed ("iser-target: Split some logic in isert_connect_request to routines") Link: https://lore.kernel.org/r/20210322161325.7491-1-lyl2019@mail.ustc.edu.cn Signed-off-by:
Lv Yunlong <lyl2019@mail.ustc.edu.cn> Acked-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by:
-
Maor Gottlieb authored
[ Upstream commit c7370080 ] Initial drop action support missed that drop action can be added to egress flow tables as well. Add the missing support. This requires making sure that dest_type isn't set to PORT which in turn exposes a possibility of passing dst while indicating number of dsts as zero. Explicitly check for number of dsts and pass the appropriate pointer. Fixes: f29de9ee ("RDMA/mlx5: Add support for drop action in DV steering") Link: https://lore.kernel.org/r/20210318135123.680759-1-leon@kernel.org Reviewed-by:
Mark Bloch <markb@nvidia.com> Signed-off-by:
Maor Gottlieb <maorg@nvidia.com> Signed-off-by:
-
Zhen Lei authored
[ Upstream commit 655c447c ] In arm_smmu_gerror_handler(), the value of the SMMU_GERROR register is filtered by GERROR_ERR_MASK. However, the GERROR_ERR_MASK does not contain the SFM bit. As a result, the subsequent error processing is not performed when only the SFM error occurs. Fixes: 48ec83bc ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices") Reported-by:
Rui Zhu <zhurui3@huawei.com> Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210324081603.1074-1-thunder.leizhen@huawei.com Signed-off-by:
-
Shengjiu Wang authored
[ Upstream commit 99067c07 ] The call sequence in wm8960_configure_clocking is ret = wm8960_configure_sysclk(); if (ret >= 0) goto configure_clock; .... ret = wm8960_configure_pll(); configure_clock: ... wm8960_configure_sysclk is called before wm8960_configure_pll, as there is bitclk relax on both functions, so wm8960_configure_sysclk always return success, then wm8960_configure_pll() never be called. With this case: aplay -Dhw:0,0 -d 5 -r 48000 -f S24_LE -c 2 audio48k24b2c.wav the required bitclk is 48000 * 24 * 2 = 2304000, bitclk got from wm8960_configure_sysclk is 3072000, but if go to wm8960_configure_pll. it can get correct bitclk 2304000. So bitclk relax condition should be removed in wm8960_configure_sysclk, then wm8960_configure_pll can be called, and there is also bitclk relax function in wm8960_configure_pll. Fixes: 3c01b9ee ("ASoC: codec: wm8960: Relax bit clock computation") Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by:
Daniel Baluta <daniel.baluta@nxp.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/1614740862-30196-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by:
-
Huang Pei authored
[ Upstream commit 509d36a9 ] When page size larger than 16KB, arguments "vaddr + size(16KB)" in "ioremap_page_range(vaddr, vaddr + size,...)" called by "add_legacy_isa_io" is not page-aligned. As loongson64 needs at least page size 16KB to get rid of cache alias, and "vaddr" is 64KB-aligned, and 64KB is largest page size supported, rounding "size" up to PAGE_SIZE is enough for all page size supported. Fixes: 6d0068ad ("MIPS: Loongson64: Process ISA Node in DeviceTree") Signed-off-by:
Huang Pei <huangpei@loongson.cn> Acked-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
-
Hanna Hawa authored
[ Upstream commit bd85125e ] A System Error (SError, followed by kernel panic) was detected when trying to print the supported pins in a pinctrl device which supports multiple pins per register. This change fixes the pcs_pin_dbg_show() in pinctrl-single driver when bits_per_mux is not zero. In addition move offset calculation and pin offset in register to common function. Fixes: 4e7e8017 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Signed-off-by:
Hanna Hawa <hhhawa@amazon.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Drew Fustini <drew@beagleboard.org> Link: https://lore.kernel.org/r/20210319152133.28705-4-hhhawa@amazon.com Signed-off-by:
-
Hanna Hawa authored
[ Upstream commit 8fa2ea20 ] Remove unused parameter 'pin_pos' from pcs_add_pin(). Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit aa6dd211 ] In commit 73f156a6 ("inetpeer: get rid of ip_id_count") I used a very small hash table that could be abused by patient attackers to reveal sensitive information. Switch to a dynamic sizing, depending on RAM size. Typical big hosts will now use 128x more storage (2 MB) to get a similar increase in security and reduction of hash collisions. As a bonus, use of alloc_large_system_hash() spreads allocated memory among all NUMA nodes. Fixes: 73f156a6 ("inetpeer: get rid of ip_id_count") Reported-by:
Amit Klein <aksecurity@gmail.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Li Huafei authored
[ Upstream commit 7990ccaf ] In ima_restore_measurement_list(), hdr[HDR_PCR].data is pointing to a buffer of type u8, which contains the dumped 32-bit pcr value. Currently, only the least significant byte is used to restore the pcr value. We should convert hdr[HDR_PCR].data to a pointer of type u32 before fetching the value to restore the correct pcr value. Fixes: 47fdee60 ("ima: use ima_parse_buf() to parse measurements headers") Signed-off-by:
Li Huafei <lihuafei1@huawei.com> Reviewed-by:
Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
-
