Skip to main content

Browse the archive

https://github.com/torvalds/linux
05 April 2024, 19:05:47 UTC
sort by:
Revision Author Date Message Commit Date
29956d0 Michael Strauss 31 August 2022, 19:10:43 UTC drm/amd/display: Assume an LTTPR is always present on fixed_vs links [WHY] LTTPRs can in very rare instsances fail to increment DPCD LTTPR count. This results in aux-i LTTPR requests to be sent to the wrong DPCD address, which causes link training failure. [HOW] Override internal repeater count if fixed_vs flag is set for a given link Reviewed-by: George Shen <George.Shen@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Michael Strauss <michael.strauss@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 21 September 2022, 21:19:25 UTC
cb0eca0 Dmytro Laktyushkin 30 August 2022, 19:16:40 UTC drm/amd/display: fix dcn315 memory channel count and width read [Why & How] Correctly set ddr5 channel width to 8 bytes Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 21 September 2022, 21:18:39 UTC
b261509 Leo Li 30 August 2022, 20:38:16 UTC drm/amd/display: Fix double cursor on non-video RGB MPO [Why] DC makes use of layer_index (zpos) when picking the HW plane to enable HW cursor on. However, some compositors will not attach zpos information to each DRM plane. Consequently, in amdgpu, we default layer_index to 0 and do not update it. This causes said DC logic to enable HW cursor on all planes of the same layer_index, which manifests as a double cursor issue if one of the planes is scaled (and hence scaling the cursor as well). [How] Use DRM core helpers to calculate a normalized_zpos value for each drm_plane_state under each crtc, within the atomic state. This helper will first consider existing zpos values, and if identical/unset, fallback to plane ID ordering. The normalized_zpos is then passed to dc_plane_info during atomic check for later use by the cursor logic. Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 21 September 2022, 21:18:15 UTC
16c6077 Alvin Lee 31 August 2022, 14:53:27 UTC drm/amd/display: Only consider pixle rate div policy for DCN32+ [Why and How] - Only consider pixel rate div policy for DCN32+ Reviewed-by: Martin Leung <Martin.Leung@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 21 September 2022, 21:17:23 UTC
88d4cea Chris Park 12 September 2022, 14:36:49 UTC drm/amd/display: Port DCN30 420 logic to DCN32 [Why] 420 modes are limited by FMT buffer width of 4096 which requires multi-pipe support in form of ODM combine. If 420 modes have greater HActive than 4096, the DML logic should accomodate whether it should be rejected, or ODM combine 2:1 or 4:1 is triggered accordingly. [How] FMT Buffer limit of 4096 in DCN32. Force ODM combine depending on HActive and FMT Buffer limit. Reject modes if TMDS 420 and above 4096. Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Chris Park <chris.park@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 21 September 2022, 21:16:22 UTC
37a0bad Mukul Joshi 07 September 2022, 14:46:58 UTC drm/amdgpu: Update PTE flags with TF enabled This patch updates the PTE flags when translate further (TF) is enabled: - With translate_further enabled, invalid PTEs can be 0. Reading consecutive invalid PTEs as 0 is considered a fault. To prevent this, ensure invalid PTEs have at least 1 bit set. - The current invalid PTE flags settings to translate a retry fault into a no-retry fault, doesn't work with TF enabled. As a result, update invalid PTE flags settings which works for both TF enabled and disabled case. Fixes: 352e683b72e79d ("drm/amdgpu: Enable translate_further to extend UTCL2 reach") Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 21 September 2022, 21:14:09 UTC
1918f2b Tony Krowiak 23 August 2022, 15:06:42 UTC s390/vfio-ap: bypass unnecessary processing of AP resources It is not necessary to go through the process of validation, linking of queues to mdev and vice versa and filtering the APQNs assigned to the matrix mdev to build an AP configuration for a guest if an adapter or domain being assigned is already assigned to the matrix mdev. Likewise, it is not necessary to proceed through the process the unassignment of an adapter, domain or control domain if it is not assigned to the matrix mdev. Since it is not necessary to process assignment of a resource already assigned or process unassignment of a resource that is been assigned, this patch will bypass all assignment/unassignment operations for an adapter, domain or control domain under these circumstances. Not only is assignment of a duplicate adapter or domain unnecessary, it will also cause a hang situation when removing the matrix mdev to which it is assigned. The reason is because the same vfio_ap_queue objects with an APQN containing the APID of the adapter or APQI of the domain being assigned will get added multiple times to the hashtable that holds them. This results in the pprev and next pointers of the hlist_node (mdev_qnode field in the vfio_ap_queue object) pointing to the queue object itself resulting in an interminable loop when the mdev is removed and the queue table is iterated to reset the queues. Cc: stable@vger.kernel.org Fixes: 11cb2419fafe ("s390/vfio-ap: manage link between queue struct and matrix mdev") Reported-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> 21 September 2022, 20:33:16 UTC
b7af938 Dan Carpenter 15 September 2022, 11:30:58 UTC i2c: mux: harden i2c_mux_alloc() against integer overflows A couple years back we went through the kernel an automatically converted size calculations to use struct_size() instead. The struct_size() calculation is protected against integer overflows. However it does not make sense to use the result from struct_size() for additional math operations as that would negate any safeness. Fixes: 1f3b69b6b939 ("i2c: mux: Use struct_size() in devm_kzalloc()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Peter Rosin <peda@axentia.se> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> 21 September 2022, 20:12:06 UTC
37f071e Asmaa Mnebhi 20 September 2022, 17:47:29 UTC i2c: mlxbf: Fix frequency calculation The i2c-mlxbf.c driver is currently broken because there is a bug in the calculation of the frequency. core_f, core_r and core_od are components read from hardware registers and are used to compute the frequency used to compute different timing parameters. The shifting mechanism used to get core_f, core_r and core_od is wrong. Use FIELD_GET to mask and shift the bitfields properly. Fixes: b5b5b32081cd206b (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC) Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com> Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> 21 September 2022, 19:43:19 UTC
999e4ea Namhyung Kim 20 September 2022, 22:28:21 UTC perf tools: Honor namespace when synthesizing build-ids It needs to enter the namespace before reading a file. Fixes: 4183a8d70a288627 ("perf tools: Allow synthesizing the build id for kernel/modules/tasks in PERF_RECORD_MMAP2") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20220920222822.2171056-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 19:08:00 UTC
356edec Arnaldo Carvalho de Melo 01 July 2021, 16:39:15 UTC tools headers cpufeatures: Sync with the kernel sources To pick the changes from: 7df548840c496b01 ("x86/bugs: Add "unknown" reporting for MMIO Stale Data") This only causes these perf files to be rebuilt: CC /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o CC /tmp/build/perf/bench/mem-memset-x86-64-asm.o And addresses this perf build warning: Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h' diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Link: https://lore.kernel.org/lkml/YysTRji90sNn2p5f@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 19:08:00 UTC
5b427df Adrian Hunter 14 September 2022, 12:24:29 UTC perf kcore_copy: Do not check /proc/modules is unchanged /proc/kallsyms and /proc/modules are compared before and after the copy in order to ensure no changes during the copy. However /proc/modules also might change due to reference counts changing even though that does not make any difference. Any modules loaded or unloaded should be visible in changes to kallsyms, so it is not necessary to check /proc/modules also anyway. Remove the comparison checking that /proc/modules is unchanged. Fixes: fc1b691d7651d949 ("perf buildid-cache: Add ability to add kcore to the cache") Reported-by: Daniel Dao <dqminh@cloudflare.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Daniel Dao <dqminh@cloudflare.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20220914122429.8770-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 19:08:00 UTC
6cc4479 Adrian Hunter 15 September 2022, 12:26:12 UTC libperf evlist: Fix polling of system-wide events Originally, (refer commit f90d194a867a5a1d ("perf evlist: Do not poll events that use the system_wide flag") there wasn't much reason to poll system-wide events because: 1. The mmaps get "merged" via set-output anyway (the per-cpu case) 2. perf reads all mmaps when any event is woken 3. system-wide mmaps do not fill up as fast as the mmaps for user selected events But there was 1 reason not to poll which was that it prevented correct termination due to POLLHUP on all user selected events. That issue is now easily resolved by using fdarray_flag__nonfilterable. With the advent of commit ae4f8ae16a078964 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps"), system-wide mmaps can be used also in the per-thread case where reason 1 does not apply. Fix the omission of system-wide events from polling by using the fdarray_flag__nonfilterable flag. Example: Before: $ perf record --no-bpf-event -vvv -e intel_pt// --per-thread uname 2>err.txt Linux $ grep 'sys_perf_event_open.*=\|pollfd' err.txt sys_perf_event_open: pid 155076 cpu -1 group_fd -1 flags 0x8 = 5 sys_perf_event_open: pid 155076 cpu -1 group_fd -1 flags 0x8 = 6 sys_perf_event_open: pid -1 cpu 0 group_fd -1 flags 0x8 = 7 sys_perf_event_open: pid -1 cpu 1 group_fd -1 flags 0x8 = 9 sys_perf_event_open: pid -1 cpu 2 group_fd -1 flags 0x8 = 10 sys_perf_event_open: pid -1 cpu 3 group_fd -1 flags 0x8 = 11 sys_perf_event_open: pid -1 cpu 4 group_fd -1 flags 0x8 = 12 sys_perf_event_open: pid -1 cpu 5 group_fd -1 flags 0x8 = 13 sys_perf_event_open: pid -1 cpu 6 group_fd -1 flags 0x8 = 14 sys_perf_event_open: pid -1 cpu 7 group_fd -1 flags 0x8 = 15 thread_data[0x55fb43c29e80]: pollfd[0] <- event_fd=5 thread_data[0x55fb43c29e80]: pollfd[1] <- event_fd=6 thread_data[0x55fb43c29e80]: pollfd[2] <- non_perf_event fd=4 After: $ perf record --no-bpf-event -vvv -e intel_pt// --per-thread uname 2>err.txt Linux $ grep 'sys_perf_event_open.*=\|pollfd' err.txt sys_perf_event_open: pid 156316 cpu -1 group_fd -1 flags 0x8 = 5 sys_perf_event_open: pid 156316 cpu -1 group_fd -1 flags 0x8 = 6 sys_perf_event_open: pid -1 cpu 0 group_fd -1 flags 0x8 = 7 sys_perf_event_open: pid -1 cpu 1 group_fd -1 flags 0x8 = 9 sys_perf_event_open: pid -1 cpu 2 group_fd -1 flags 0x8 = 10 sys_perf_event_open: pid -1 cpu 3 group_fd -1 flags 0x8 = 11 sys_perf_event_open: pid -1 cpu 4 group_fd -1 flags 0x8 = 12 sys_perf_event_open: pid -1 cpu 5 group_fd -1 flags 0x8 = 13 sys_perf_event_open: pid -1 cpu 6 group_fd -1 flags 0x8 = 14 sys_perf_event_open: pid -1 cpu 7 group_fd -1 flags 0x8 = 15 thread_data[0x55cc19e58e80]: pollfd[0] <- event_fd=5 thread_data[0x55cc19e58e80]: pollfd[1] <- event_fd=6 thread_data[0x55cc19e58e80]: pollfd[2] <- event_fd=7 thread_data[0x55cc19e58e80]: pollfd[3] <- event_fd=9 thread_data[0x55cc19e58e80]: pollfd[4] <- event_fd=10 thread_data[0x55cc19e58e80]: pollfd[5] <- event_fd=11 thread_data[0x55cc19e58e80]: pollfd[6] <- event_fd=12 thread_data[0x55cc19e58e80]: pollfd[7] <- event_fd=13 thread_data[0x55cc19e58e80]: pollfd[8] <- event_fd=14 thread_data[0x55cc19e58e80]: pollfd[9] <- event_fd=15 thread_data[0x55cc19e58e80]: pollfd[10] <- non_perf_event fd=4 Fixes: ae4f8ae16a078964 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220915122612.81738-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 19:08:00 UTC
ca76d7d Adrian Hunter 15 September 2022, 12:26:11 UTC perf record: Fix cpu mask bit setting for mixed mmaps With mixed per-thread and (system-wide) per-cpu maps, the "any cpu" value -1 must be skipped when setting CPU mask bits. Prior to commit cbd7bfc7fd99acdd ("tools/perf: Fix out of bound access to cpu mask array") the invalid setting went unnoticed, but since then it causes perf record to fail with an error. Example: Before: $ perf record -e intel_pt// --per-thread uname Failed to initialize parallel data streaming masks After: $ perf record -e intel_pt// --per-thread uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.068 MB perf.data ] Fixes: ae4f8ae16a078964 ("libperf evlist: Allow mixing per-thread and per-cpu mmaps") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220915122612.81738-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 19:08:00 UTC
e1dda48 Namhyung Kim 14 September 2022, 18:33:38 UTC perf test: Skip wp modify test on old kernels It uses PERF_EVENT_IOC_MODIFY_ATTRIBUTES ioctl. The kernel would return ENOTTY if it's not supported. Update the skip reason in that case. Committer notes: On s/390 the args aren't used, so need to be marked __maybe_unused. Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Bangoria <ravi.bangoria@amd.com> Link: https://lore.kernel.org/r/20220914183338.546357-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 19:07:32 UTC
9614369 Rafael J. Wysocki 21 September 2022, 17:57:31 UTC Merge tag 'opp-fixes-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull OPP fixes for 6.0 from Viresh Kumar: "- Fix un-initialized variable usage (Christophe JAILLET). - Add missing DT properties (Rob Herring)." * tag 'opp-fixes-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: dt-bindings: opp: Add missing (unevaluated|additional)Properties on child nodes OPP: Fix an un-initialized variable usage 21 September 2022, 17:57:31 UTC
dc164f4 Linus Torvalds 21 September 2022, 17:14:56 UTC Merge tag 'for-linus-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux Pull UML fixes from Richard Weinberger: - Various fixes for build warnings - Fix default kernel command line * tag 'for-linus-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux: arch: um: Mark the stack non-executable to fix a binutils warning um: Prevent KASAN splats in dump_stack() um: fix default console kernel parameter um: Cleanup compiler warning in arch/x86/um/tls_32.c um: Cleanup syscall_handler_t cast in syscalls_32.h 21 September 2022, 17:14:56 UTC
26c9564 Linus Torvalds 21 September 2022, 16:31:19 UTC Merge tag 'mips-fixes_6.0_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fixes from Thomas Bogendoerfer: - fix missing export for Lantiq watchdog driver - fix ethernet phy interface setup for Loongson32 * tag 'mips-fixes_6.0_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: Loongson32: Fix PHY-mode being left unspecified MIPS: lantiq: export clk_get_io() for lantiq_wdt.ko 21 September 2022, 16:31:19 UTC
88e6546 Linus Torvalds 21 September 2022, 16:25:32 UTC Merge tag 'dmaengine-fix-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine fixes from Vinod Koul: "A couple of small driver fixes: - xilinx_dma: devm_platform_ioremap_resource error handling, dma_set_mask_and_coherent failure handling, dt property read cleanup - refcount leak fix for of_xudma_dev_get() - zynqmp_dma: coverity fix for enum typecast" * tag 'dmaengine-fix-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: dmaengine: zynqmp_dma: Typecast with enum to fix the coverity warning dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get() dmaengine: xilinx_dma: Report error in case of dma_set_mask_and_coherent API failure dmaengine: xilinx_dma: cleanup for fetching xlnx,num-fstores property dmaengine: xilinx_dma: Fix devm_platform_ioremap_resource error handling 21 September 2022, 16:25:32 UTC
06f7db9 Linus Torvalds 21 September 2022, 16:12:52 UTC Merge tag 'iommu-fixes-v6.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: "Two fixes for Intel VT-d: - Check the right capability bit for 5-level page table support. - Revert a previous fix which caused a regression with Thunderbolt devices" * tag 'iommu-fixes-v6.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Check correct capability for sagaw determination Revert "iommu/vt-d: Fix possible recursive locking in intel_iommu_init()" 21 September 2022, 16:12:52 UTC
5ce9410 Linus Torvalds 21 September 2022, 16:07:59 UTC Merge tag 'sound-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A bit more changes than wished, but still manageable amount. Most of commits are HD-audio specific device fixes / quirks, while there is a revert for the previous fix due to regressions and a double-free fix in ALSA core code" * tag 'sound-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: Revert "ALSA: usb-audio: Split endpoint setups for hw_params and prepare" ALSA: core: Fix double-free at snd_card_new() ALSA: hda/realtek: Add a quirk for HP OMEN 16 (8902) mute LED ALSA: hda/hdmi: Fix the converter reuse for the silent stream ALSA: hda/realtek: Add quirk for ASUS GA503R laptop ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jack ALSA: hda/realtek: Add pincfg for ASUS G513 HP jack ALSA: hda/realtek: Re-arrange quirk table entries ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5530 laptop ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5570 laptop ALSA: hda: Fix Nvidia dp infoframe ALSA: hda/realtek: Add quirk for Huawei WRT-WX9 ALSA: hda/tegra: set depop delay for tegra ALSA: hda: add Intel 5 Series / 3400 PCI DID ALSA: hda: Fix hang at HD-audio codec unbinding due to refcount saturation 21 September 2022, 16:07:59 UTC
48062bb Linus Torvalds 21 September 2022, 15:40:57 UTC Merge tag 'exfat-for-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat Pull exfat fix from Namjae Jeon: - fix integer overflow on large partitions * tag 'exfat-for-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat: exfat: fix overflow for large capacity partition 21 September 2022, 15:40:57 UTC
189e7d8 Matthew Rosato 20 September 2022, 19:30:25 UTC KVM: s390: pci: register pci hooks without interpretation The kvm registration hooks must be registered even if the facilities necessary for zPCI interpretation are unavailable, as vfio-pci-zdev will expect to use the hooks regardless. This fixes an issue where vfio-pci-zdev will fail its open function because of a missing kvm_register when running on hardware that does not support zPCI interpretation. Fixes: ca922fecda6c ("KVM: s390: pci: Hook to access KVM lowlevel from VFIO") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Link: https://lore.kernel.org/r/20220920193025.135655-1-mjrosato@linux.ibm.com Message-Id: <20220920193025.135655-1-mjrosato@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> 21 September 2022, 14:18:38 UTC
70ba8fa Matthew Rosato 07 September 2022, 15:59:52 UTC KVM: s390: pci: fix GAIT physical vs virtual pointers usage The GAIT and all of its entries must be represented by physical addresses as this structure is shared with underlying firmware. We can keep a virtual address of the GAIT origin in order to handle processing in the kernel, but when traversing the entries we must again convert the physical AISB stored in that GAIT entry into a virtual address in order to process it. Note: this currently doesn't fix a real bug, since virtual addresses are indentical to physical ones. Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Acked-by: Nico Boehr <nrb@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/r/20220907155952.87356-1-mjrosato@linux.ibm.com Message-Id: <20220907155952.87356-1-mjrosato@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> 21 September 2022, 14:18:38 UTC
b3cefd6 Janis Schoetterl-Glausch 25 August 2022, 19:25:40 UTC KVM: s390: Pass initialized arg even if unused This silences smatch warnings reported by kbuild bot: arch/s390/kvm/gaccess.c:859 guest_range_to_gpas() error: uninitialized symbol 'prot'. arch/s390/kvm/gaccess.c:1064 access_guest_with_key() error: uninitialized symbol 'prot'. This is because it cannot tell that the value is not used in this case. The trans_exc* only examine prot if code is PGM_PROTECTION. Pass a dummy value for other codes. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/r/20220825192540.1560559-1-scgl@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> 21 September 2022, 14:18:35 UTC
e8c924a Matthew Rosato 15 September 2022, 17:55:14 UTC KVM: s390: pci: fix plain integer as NULL pointer warnings Fix some sparse warnings that a plain integer 0 is being used instead of NULL. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220915175514.167899-1-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> 21 September 2022, 14:18:30 UTC
375a683 Jakub Kicinski 21 September 2022, 13:52:32 UTC Merge tag 'linux-can-fixes-for-6.0-20220921' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2022-09-21 The 1st patch is by me, targets the flexcan driver and fixes a potential system hang on single core systems under high CAN packet rate. The next 2 patches are also by me and target the gs_usb driver. A potential race condition during the ndo_open callback as well as the return value if the ethtool identify feature is not supported are fixed. * tag 'linux-can-fixes-for-6.0-20220921' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: gs_usb: gs_usb_set_phys_id(): return with error if identify is not supported can: gs_usb: gs_can_open(): fix race dev->can.state condition can: flexcan: flexcan_mailbox_read() fix return value for drop = true ==================== Link: https://lore.kernel.org/r/20220921083609.419768-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> 21 September 2022, 13:52:32 UTC
babd043 Lieven Hey 15 September 2022, 09:29:10 UTC perf jit: Include program header in ELF files The missing header makes it hard for programs like elfutils to open these files. Fixes: 2d86612aacb7805f ("perf symbol: Correct address for bss symbols") Reviewed-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Lieven Hey <lieven.hey@kdab.com> Tested-by: Leo Yan <leo.yan@linaro.org> Cc: Leo Yan <leo.yan@linaro.org> Link: https://lore.kernel.org/r/20220915092910.711036-1-lieven.hey@kdab.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 13:30:55 UTC
7901086 Namhyung Kim 16 September 2022, 18:41:32 UTC perf test: Add a new test for perf stat cgroup BPF counter $ sudo ./perf test -v each-cgroup 96: perf stat --bpf-counters --for-each-cgroup test : --- start --- test child forked, pid 79600 test child finished with 0 ---- end ---- perf stat --bpf-counters --for-each-cgroup test: Ok Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <songliubraving@fb.com> Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20220916184132.1161506-5-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 13:30:55 UTC
8a92605 Namhyung Kim 16 September 2022, 18:41:31 UTC perf stat: Use evsel->core.cpus to iterate cpus in BPF cgroup counters If it mixes core and uncore events, each evsel would have different cpu map. But it assumed they are same with evlist's all_cpus and accessed by the same index. This resulted in a crash like below. $ perf stat -a --bpf-counters --for-each_cgroup ^. -e cycles,imc/cas_count_read/ sleep 1 Segmentation fault While it's not recommended to use uncore events for cgroup aggregation, it should not crash. Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <songliubraving@fb.com> Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20220916184132.1161506-4-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 13:30:55 UTC
3da3523 Namhyung Kim 16 September 2022, 18:41:30 UTC perf stat: Fix cpu map index in bperf cgroup code The previous cpu map introduced a bug in the bperf cgroup counter. This results in a failure when user gives a partial cpu map starting from non-zero. $ sudo ./perf stat -C 1-2 --bpf-counters --for-each-cgroup ^. sleep 1 libbpf: prog 'on_cgrp_switch': failed to create BPF link for perf_event FD 0: -9 (Bad file descriptor) Failed to attach cgroup program To get the FD of an evsel, it should use a map index not the CPU number. Fixes: 0255571a16059c8e ("perf cpumap: Switch to using perf_cpu_map API") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: bpf@vger.kernel.org Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/r/20220916184132.1161506-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 13:30:55 UTC
0d77326 Namhyung Kim 16 September 2022, 18:41:29 UTC perf stat: Fix BPF program section name It seems the recent libbpf got more strict about the section name. I'm seeing a failure like this: $ sudo ./perf stat -a --bpf-counters --for-each-cgroup ^. sleep 1 libbpf: prog 'on_cgrp_switch': missing BPF prog type, check ELF section name 'perf_events' libbpf: prog 'on_cgrp_switch': failed to load: -22 libbpf: failed to load object 'bperf_cgroup_bpf' libbpf: failed to load BPF skeleton 'bperf_cgroup_bpf': -22 Failed to load cgroup skeleton The section name should be 'perf_event' (without the trailing 's'). Although it's related to the libbpf change, it'd be better fix the section name in the first place. Fixes: 944138f048f7d759 ("perf stat: Enable BPF counter with --for-each-cgroup") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: bpf@vger.kernel.org Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/r/20220916184132.1161506-2-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 21 September 2022, 13:30:55 UTC
ab4bbde Greg Kroah-Hartman 21 September 2022, 13:26:45 UTC Merge tag 'fpga-for-6.0-final' of git://git.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga into char-misc-linus Xu writes: FPGA Manager changes for 6.0-final Intel m10 bmc secure update - Russ's change fixes the memory leak for a sysfs node reading All patches have been reviewed on the mailing list, and have been in the last linux-next releases (as part of our for-6.0 branch). Signed-off-by: Xu Yilun <yilun.xu@intel.com> * tag 'fpga-for-6.0-final' of git://git.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga: fpga: m10bmc-sec: Fix possible memory leak of flash_buf 21 September 2022, 13:26:45 UTC
65e5d27 Jianglei Nie 14 September 2022, 01:42:38 UTC net: atlantic: fix potential memory leak in aq_ndev_close() If aq_nic_stop() fails, aq_ndev_close() returns err without calling aq_nic_deinit() to release the relevant memory and resource, which will lead to a memory leak. We can fix it by deleting the if condition judgment and goto statement to call aq_nic_deinit() directly after aq_nic_stop() to fix the memory leak. Signed-off-by: Jianglei Nie <niejianglei2021@163.com> Signed-off-by: David S. Miller <davem@davemloft.net> 21 September 2022, 11:50:57 UTC
1548978 Yi Liu 21 September 2022, 02:40:54 UTC iommu/vt-d: Check correct capability for sagaw determination Check 5-level paging capability for 57 bits address width instead of checking 1GB large page capability. Fixes: 53fc7ad6edf2 ("iommu/vt-d: Correctly calculate sagaw value of IOMMU") Cc: stable@vger.kernel.org Reported-by: Raghunathan Srinivasan <raghunathan.srinivasan@intel.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Raghunathan Srinivasan <raghunathan.srinivasan@intel.com> Link: https://lore.kernel.org/r/20220916071212.2223869-2-yi.l.liu@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> 21 September 2022, 08:22:54 UTC
7ebb5f8 Lu Baolu 21 September 2022, 02:40:53 UTC Revert "iommu/vt-d: Fix possible recursive locking in intel_iommu_init()" This reverts commit 9cd4f1434479f1ac25c440c421fbf52069079914. Some issues were reported on the original commit. Some thunderbolt devices don't work anymore due to the following DMA fault. DMAR: DRHD: handling fault status reg 2 DMAR: [INTR-REMAP] Request device [09:00.0] fault index 0x8080 [fault reason 0x25] Blocked a compatibility format interrupt request Bring it back for now to avoid functional regression. Fixes: 9cd4f1434479f ("iommu/vt-d: Fix possible recursive locking in intel_iommu_init()") Link: https://lore.kernel.org/linux-iommu/485A6EA5-6D58-42EA-B298-8571E97422DE@getmailspring.com/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=216497 Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: <stable@vger.kernel.org> # 5.19.x Reported-and-tested-by: George Hilliard <thirtythreeforty@gmail.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20220920081701.3453504-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de> 21 September 2022, 08:22:54 UTC
79a392a David S. Miller 21 September 2022, 08:07:53 UTC Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Florian Westphal says: ==================== netfilter: bugfixes for net The following set contains netfilter fixes for the *net* tree. Regressions (rc only): recent ebtables crash fix was incomplete, it added a memory leak. The patch to fix possible buffer overrun for BIG TCP in ftp conntrack tried to be too clever, we cannot re-use ct->lock: NAT engine might grab it again -> deadlock. Revert back to a global spinlock. Both from myself. Remove the documentation for the recently removed 'nf_conntrack_helper' sysctl as well, from Pablo Neira. The static_branch_inc() that guards the 'chain stats enabled' path needs to be deferred further, until the entire transaction was created. From Tetsuo Handa. Older bugs: Since 5.3: nf_tables_addchain may leak pcpu memory in error path when offloading fails. Also from Tetsuo Handa. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 21 September 2022, 08:07:53 UTC
0f2211f Marc Kleine-Budde 18 August 2022, 12:10:08 UTC can: gs_usb: gs_usb_set_phys_id(): return with error if identify is not supported Until commit 409c188c57cd ("can: tree-wide: advertise software timestamping capabilities") the ethtool_ops was only assigned for devices which support the GS_CAN_FEATURE_IDENTIFY feature. That commit assigns ethtool_ops unconditionally. This results on controllers without GS_CAN_FEATURE_IDENTIFY support for the following ethtool error: | $ ethtool -p can0 1 | Cannot identify NIC: Broken pipe Restore the correct error value by checking for GS_CAN_FEATURE_IDENTIFY in the gs_usb_set_phys_id() function. | $ ethtool -p can0 1 | Cannot identify NIC: Operation not supported While there use the variable "netdev" for the "struct net_device" pointer and "dev" for the "struct gs_can" pointer as in the rest of the driver. Fixes: 409c188c57cd ("can: tree-wide: advertise software timestamping capabilities") Link: http://lore.kernel.org/all/20220818143853.2671854-1-mkl@pengutronix.de Cc: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 21 September 2022, 07:48:52 UTC
5440428 Marc Kleine-Budde 20 September 2022, 09:40:56 UTC can: gs_usb: gs_can_open(): fix race dev->can.state condition The dev->can.state is set to CAN_STATE_ERROR_ACTIVE, after the device has been started. On busy networks the CAN controller might receive CAN frame between and go into an error state before the dev->can.state is assigned. Assign dev->can.state before starting the controller to close the race window. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/all/20220920195216.232481-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 21 September 2022, 07:48:51 UTC
a09721d Marc Kleine-Budde 11 August 2022, 08:25:44 UTC can: flexcan: flexcan_mailbox_read() fix return value for drop = true The following happened on an i.MX25 using flexcan with many packets on the bus: The rx-offload queue reached a length more than skb_queue_len_max. In can_rx_offload_offload_one() the drop variable was set to true which made the call to .mailbox_read() (here: flexcan_mailbox_read()) to _always_ return ERR_PTR(-ENOBUFS) and drop the rx'ed CAN frame. So can_rx_offload_offload_one() returned ERR_PTR(-ENOBUFS), too. can_rx_offload_irq_offload_fifo() looks as follows: | while (1) { | skb = can_rx_offload_offload_one(offload, 0); | if (IS_ERR(skb)) | continue; | if (!skb) | break; | ... | } The flexcan driver wrongly always returns ERR_PTR(-ENOBUFS) if drop is requested, even if there is no CAN frame pending. As the i.MX25 is a single core CPU, while the rx-offload processing is active, there is no thread to process packets from the offload queue. So the queue doesn't get any shorter and this results is a tight loop. Instead of always returning ERR_PTR(-ENOBUFS) if drop is requested, return NULL if no CAN frame is pending. Changes since v1: https://lore.kernel.org/all/20220810144536.389237-1-u.kleine-koenig@pengutronix.de - don't break in can_rx_offload_irq_offload_fifo() in case of an error, return NULL in flexcan_mailbox_read() in case of no pending CAN frame instead Fixes: 4e9c9484b085 ("can: rx-offload: Prepare for CAN FD support") Link: https://lore.kernel.org/all/20220811094254.1864367-1-mkl@pengutronix.de Cc: stable@vger.kernel.org # v5.5 Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Thorsten Scherer <t.scherer@eckelmann.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 21 September 2022, 07:48:51 UTC
69bef19 Meng Li 21 September 2022, 03:20:20 UTC gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully When running gpio test on nxp-ls1028 platform with below command gpiomon --num-events=3 --rising-edge gpiochip1 25 There will be a warning trace as below: Call trace: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... el0t_64_sync+0x1a0/0x1a4 The reason of this issue is that calling request_threaded_irq() function failed, and then lineevent_free() is invoked to release the resource. Since the lineevent_state::irq was already set, so the subsequent invocation of free_irq() would trigger the above warning call trace. To fix this issue, set the lineevent_state::irq after the IRQ register successfully. Fixes: 468242724143 ("gpiolib: cdev: refactor lineevent cleanup into lineevent_free") Cc: stable@vger.kernel.org Signed-off-by: Meng Li <Meng.Li@windriver.com> Reviewed-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> 21 September 2022, 07:32:11 UTC
21a9acc Dongliang Mu 19 September 2022, 03:12:49 UTC gpio: tqmx86: fix uninitialized variable girq The commit 924610607f19 ("gpio: tpmx86: Move PM device over to irq domain") adds a dereference of girq that may be uninitialized. Fix this by moving irq_domain_set_pm_device into if true branch as suggested by Marc Zyngier. Fixes: 924610607f19 ("gpio: tpmx86: Move PM device over to irq domain") Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> 21 September 2022, 07:31:22 UTC
bd71558 David Gow 21 September 2022, 06:48:55 UTC arch: um: Mark the stack non-executable to fix a binutils warning Since binutils 2.39, ld will print a warning if any stack section is executable, which is the default for stack sections on files without a .note.GNU-stack section. This was fixed for x86 in commit ffcf9c5700e4 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"), but remained broken for UML, resulting in several warnings: /usr/bin/ld: warning: arch/x86/um/vdso/vdso.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: vmlinux has a LOAD segment with RWX permissions Link both the VDSO and vmlinux with -z noexecstack, fixing the warnings about .note.GNU-stack sections. In addition, pass --no-warn-rwx-segments to dodge the remaining warnings about LOAD segments with RWX permissions in the kallsyms objects. (Note that this flag is apparently not available on lld, so hide it behind a test for BFD, which is what the x86 patch does.) Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136 Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Lukas Straub <lukasstraub2@web.de> Tested-by: Lukas Straub <lukasstraub2@web.de> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Richard Weinberger <richard@nod.at> 21 September 2022, 07:11:42 UTC
6a1dbfe Geert Uytterhoeven 19 September 2022, 14:48:28 UTC net: sh_eth: Fix PHY state warning splat during system resume Since commit 744d23c71af39c7d ("net: phy: Warn about incorrect mdio_bus_phy_resume() state"), a warning splat is printed during system resume with Wake-on-LAN disabled: WARNING: CPU: 0 PID: 626 at drivers/net/phy/phy_device.c:323 mdio_bus_phy_resume+0xbc/0xe4 As the Renesas SuperH Ethernet driver already calls phy_{stop,start}() in its suspend/resume callbacks, it is sufficient to just mark the MAC responsible for managing the power state of the PHY. Fixes: fba863b816049b03 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/c6e1331b9bef61225fa4c09db3ba3e2e7214ba2d.1663598886.git.geert+renesas@glider.be Signed-off-by: Jakub Kicinski <kuba@kernel.org> 21 September 2022, 00:05:50 UTC
4924c0c Geert Uytterhoeven 19 September 2022, 14:48:00 UTC net: ravb: Fix PHY state warning splat during system resume Since commit 744d23c71af39c7d ("net: phy: Warn about incorrect mdio_bus_phy_resume() state"), a warning splat is printed during system resume with Wake-on-LAN disabled: WARNING: CPU: 0 PID: 1197 at drivers/net/phy/phy_device.c:323 mdio_bus_phy_resume+0xbc/0xc8 As the Renesas Ethernet AVB driver already calls phy_{stop,start}() in its suspend/resume callbacks, it is sufficient to just mark the MAC responsible for managing the power state of the PHY. Fixes: fba863b816049b03 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/8ec796f47620980fdd0403e21bd8b7200b4fa1d4.1663598796.git.geert+renesas@glider.be Signed-off-by: Jakub Kicinski <kuba@kernel.org> 21 September 2022, 00:05:46 UTC
d250889 Florian Westphal 20 September 2022, 16:31:30 UTC netfilter: nf_ct_ftp: fix deadlock when nat rewrite is needed We can't use ct->lock, this is already used by the seqadj internals. When using ftp helper + nat, seqadj will attempt to acquire ct->lock again. Revert back to a global lock for now. Fixes: c783a29c7e59 ("netfilter: nf_ct_ftp: prefer skb_linearize") Reported-by: Bruno de Paula Larini <bruno.larini@riosoft.com.br> Signed-off-by: Florian Westphal <fw@strlen.de> 20 September 2022, 21:50:03 UTC
62ce44c Florian Westphal 20 September 2022, 12:20:17 UTC netfilter: ebtables: fix memory leak when blob is malformed The bug fix was incomplete, it "replaced" crash with a memory leak. The old code had an assignment to "ret" embedded into the conditional, restore this. Fixes: 7997eff82828 ("netfilter: ebtables: reject blobs that don't provide all entry points") Reported-and-tested-by: syzbot+a24c5252f3e3ab733464@syzkaller.appspotmail.com Signed-off-by: Florian Westphal <fw@strlen.de> 20 September 2022, 21:50:03 UTC
9a4d6dd Tetsuo Handa 12 September 2022, 13:58:51 UTC netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain() It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") Signed-off-by: Florian Westphal <fw@strlen.de> 20 September 2022, 21:50:03 UTC
921ebde Tetsuo Handa 12 September 2022, 12:41:00 UTC netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain() syzbot is reporting underflow of nft_counters_enabled counter at nf_tables_addchain() [1], for commit 43eb8949cfdffa76 ("netfilter: nf_tables: do not leave chain stats enabled on error") missed that nf_tables_chain_destroy() after nft_basechain_init() in the error path of nf_tables_addchain() decrements the counter because nft_basechain_init() makes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag. Increment the counter immediately after returning from nft_basechain_init(). Link: https://syzkaller.appspot.com/bug?extid=b5d82a651b71cd8a75ab [1] Reported-by: syzbot <syzbot+b5d82a651b71cd8a75ab@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: syzbot <syzbot+b5d82a651b71cd8a75ab@syzkaller.appspotmail.com> Fixes: 43eb8949cfdffa76 ("netfilter: nf_tables: do not leave chain stats enabled on error") Signed-off-by: Florian Westphal <fw@strlen.de> 20 September 2022, 21:50:03 UTC
76b907e Pablo Neira Ayuso 09 September 2022, 10:42:11 UTC netfilter: conntrack: remove nf_conntrack_helper documentation This toggle has been already remove by b118509076b3 ("netfilter: remove nf_conntrack_helper sysctl and modparam toggles"). Remove the documentation entry for this toggle too. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de> 20 September 2022, 21:50:03 UTC
603ccb3 Bhupesh Sharma 15 September 2022, 11:28:04 UTC MAINTAINERS: Add myself as a reviewer for Qualcomm ETHQOS Ethernet driver As suggested by Vinod, adding myself as the reviewer for the Qualcomm ETHQOS Ethernet driver. Recently I have enabled this driver on a few Qualcomm SoCs / boards and hence trying to keep a close eye on it. Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Acked-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20220915112804.3950680-1-bhupesh.sharma@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 20:42:55 UTC
8ac7132 Mateusz Palczewski 26 August 2022, 08:31:23 UTC ice: Fix interface being down after reset with link-down-on-close flag on When performing a reset on ice driver with link-down-on-close flag on interface would always stay down. Fix this by moving a check of this flag to ice_stop() that is called only when user wants to bring interface down. Fixes: ab4ab73fc1ec ("ice: Add ethtool private flag to make forcing link down optional") Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Petr Oros <poros@redhat.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> 20 September 2022, 20:30:51 UTC
122045c Michal Swiatkowski 08 August 2022, 09:58:54 UTC ice: config netdev tc before setting queues number After lowering number of tx queues the warning appears: "Number of in use tx queues changed invalidating tc mappings. Priority traffic classification disabled!" Example command to reproduce: ethtool -L enp24s0f0 tx 36 rx 36 Fix this by setting correct tc mapping before setting real number of queues on netdev. Fixes: 0754d65bd4be5 ("ice: Add infrastructure for mqprio support via ndo_setup_tc") Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> 20 September 2022, 20:30:51 UTC
da84724 Jakub Kicinski 20 September 2022, 18:41:17 UTC Merge branch 'fixes-for-tc-taprio-software-mode' Vladimir Oltean says: ==================== Fixes for tc-taprio software mode While working on some new features for tc-taprio, I found some strange behavior which looked like bugs. I was able to eventually trigger a NULL pointer dereference. This patch set fixes 2 issues I saw. Detailed explanation in patches. ==================== Link: https://lore.kernel.org/r/20220915100802.2308279-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:41:18 UTC
1461d21 Vladimir Oltean 15 September 2022, 10:08:02 UTC net/sched: taprio: make qdisc_leaf() see the per-netdev-queue pfifo child qdiscs taprio can only operate as root qdisc, and to that end, there exists the following check in taprio_init(), just as in mqprio: if (sch->parent != TC_H_ROOT) return -EOPNOTSUPP; And indeed, when we try to attach taprio to an mqprio child, it fails as expected: $ tc qdisc add dev swp0 root handle 1: mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:2 taprio num_tc 8 \ map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ base-time 0 sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Error: sch_taprio: Can only be attached as root qdisc. (extack message added by me) But when we try to attach a taprio child to a taprio root qdisc, surprisingly it doesn't fail: $ tc qdisc replace dev swp0 root handle 1: taprio num_tc 8 \ map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ base-time 0 sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI $ tc qdisc replace dev swp0 parent 1:2 taprio num_tc 8 \ map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ base-time 0 sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI This is because tc_modify_qdisc() behaves differently when mqprio is root, vs when taprio is root. In the mqprio case, it finds the parent qdisc through p = qdisc_lookup(dev, TC_H_MAJ(clid)), and then the child qdisc through q = qdisc_leaf(p, clid). This leaf qdisc q has handle 0, so it is ignored according to the comment right below ("It may be default qdisc, ignore it"). As a result, tc_modify_qdisc() goes through the qdisc_create() code path, and this gives taprio_init() a chance to check for sch_parent != TC_H_ROOT and error out. Whereas in the taprio case, the returned q = qdisc_leaf(p, clid) is different. It is not the default qdisc created for each netdev queue (both taprio and mqprio call qdisc_create_dflt() and keep them in a private q->qdiscs[], or priv->qdiscs[], respectively). Instead, taprio makes qdisc_leaf() return the _root_ qdisc, aka itself. When taprio does that, tc_modify_qdisc() goes through the qdisc_change() code path, because the qdisc layer never finds out about the child qdisc of the root. And through the ->change() ops, taprio has no reason to check whether its parent is root or not, just through ->init(), which is not called. The problem is the taprio_leaf() implementation. Even though code wise, it does the exact same thing as mqprio_leaf() which it is copied from, it works with different input data. This is because mqprio does not attach itself (the root) to each device TX queue, but one of the default qdiscs from its private array. In fact, since commit 13511704f8d7 ("net: taprio offload: enforce qdisc to netdev queue mapping"), taprio does this too, but just for the full offload case. So if we tried to attach a taprio child to a fully offloaded taprio root qdisc, it would properly fail too; just not to a software root taprio. To fix the problem, stop looking at the Qdisc that's attached to the TX queue, and instead, always return the default qdiscs that we've allocated (and to which we privately enqueue and dequeue, in software scheduling mode). Since Qdisc_class_ops :: leaf is only called from tc_modify_qdisc(), the risk of unforeseen side effects introduced by this change is minimal. Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:41:14 UTC
db46e3a Vladimir Oltean 15 September 2022, 10:08:01 UTC net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on an invalid set of flags. As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIO_FLAGS_INVALID, and the calling of taprio_enable_offload(). This is because drivers do not expect the offload to be disabled when it was never enabled. The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc: $ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2c Fix this by keeping track of the operations we made, and undo the offload only if we actually did it. I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64_t picos_per_byte". Now the first cache line looks like below: $ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ Fixes: 9c66d1564676 ("taprio: Add support for hardware offloading") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:41:14 UTC
76dd072 Ido Schimmel 16 September 2022, 08:48:21 UTC ipv6: Fix crash when IPv6 is administratively disabled The global 'raw_v6_hashinfo' variable can be accessed even when IPv6 is administratively disabled via the 'ipv6.disable=1' kernel command line option, leading to a crash [1]. Fix by restoring the original behavior and always initializing the variable, regardless of IPv6 support being administratively disabled or not. [1] BUG: unable to handle page fault for address: ffffffffffffffc8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 173e18067 P4D 173e18067 PUD 173e1a067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 3 PID: 271 Comm: ss Not tainted 6.0.0-rc4-custom-00136-g0727a9a5fbc1 #1396 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:raw_diag_dump+0x310/0x7f0 [...] Call Trace: <TASK> __inet_diag_dump+0x10f/0x2e0 netlink_dump+0x575/0xfd0 __netlink_dump_start+0x67b/0x940 inet_diag_handler_cmd+0x273/0x2d0 sock_diag_rcv_msg+0x317/0x440 netlink_rcv_skb+0x15e/0x430 sock_diag_rcv+0x2b/0x40 netlink_unicast+0x53b/0x800 netlink_sendmsg+0x945/0xe60 ____sys_sendmsg+0x747/0x960 ___sys_sendmsg+0x13a/0x1e0 __sys_sendmsg+0x118/0x1e0 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 0daf07e52709 ("raw: convert raw sockets to RCU") Reported-by: Roberto Ricci <rroberto2r@gmail.com> Tested-by: Roberto Ricci <rroberto2r@gmail.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20220916084821.229287-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:27:32 UTC
5641c75 Vladimir Oltean 16 September 2022, 13:32:09 UTC net: enetc: deny offload of tc-based TSN features on VF interfaces TSN features on the ENETC (taprio, cbs, gate, police) are configured through a mix of command BD ring messages and port registers: enetc_port_rd(), enetc_port_wr(). Port registers are a region of the ENETC memory map which are only accessible from the PCIe Physical Function. They are not accessible from the Virtual Functions. Moreover, attempting to access these registers crashes the kernel: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15 fsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0 $ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2 Unable to handle kernel paging request at virtual address ffff800009551a08 Internal error: Oops: 96000007 [#1] PREEMPT SMP pc : enetc_setup_tc_taprio+0x170/0x47c lr : enetc_setup_tc_taprio+0x16c/0x47c Call trace: enetc_setup_tc_taprio+0x170/0x47c enetc_setup_tc+0x38/0x2dc taprio_change+0x43c/0x970 taprio_init+0x188/0x1e0 qdisc_create+0x114/0x470 tc_modify_qdisc+0x1fc/0x6c0 rtnetlink_rcv_msg+0x12c/0x390 Split enetc_setup_tc() into separate functions for the PF and for the VF drivers. Also remove enetc_qos.o from being included into enetc-vf.ko, since it serves absolutely no purpose there. Fixes: 34c6adf1977b ("enetc: Configure the Time-Aware Scheduler via tc-taprio offload") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20220916133209.3351399-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:27:10 UTC
fed38e6 Vladimir Oltean 16 September 2022, 13:32:08 UTC net: enetc: move enetc_set_psfp() out of the common enetc_set_features() The VF netdev driver shouldn't respond to changes in the NETIF_F_HW_TC flag; only PFs should. Moreover, TSN-specific code should go to enetc_qos.c, which should not be included in the VF driver. Fixes: 79e499829f3f ("net: enetc: add hw tc hw offload features for PSPF capability") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20220916133209.3351399-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:27:09 UTC
0507246 Jakub Kicinski 20 September 2022, 18:26:18 UTC Merge branch 'wireguard-patches-for-6-0-rc6' Jason A. Donenfeld says: ==================== wireguard patches for 6.0-rc6 1) The ratelimiter timing test doesn't help outside of development, yet it is currently preventing the module from being inserted on some kernels when it flakes at insertion time. So we disable it. 2) A fix for a build error on UML, caused by a recent change in a different tree. 3) A WARN_ON() is triggered by Kees' new fortified memcpy() patch, due to memcpy()ing over a sockaddr pointer with the size of a sockaddr_in[6]. The type safe fix is pretty simple. Given how classic of a thing sockaddr punning is, I suspect this may be the first in a few patches like this throughout the net tree, once Kees' fortify series is more widely deployed (current it's just in next). ==================== Link: https://lore.kernel.org/r/20220916143740.831881-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:26:19 UTC
26c0131 Jason A. Donenfeld 16 September 2022, 14:37:40 UTC wireguard: netlink: avoid variable-sized memcpy on sockaddr Doing a variable-sized memcpy is slower, and the compiler isn't smart enough to turn this into a constant-size assignment. Further, Kees' latest fortified memcpy will actually bark, because the destination pointer is type sockaddr, not explicitly sockaddr_in or sockaddr_in6, so it thinks there's an overflow: memcpy: detected field-spanning write (size 28) of single field "&endpoint.addr" at drivers/net/wireguard/netlink.c:446 (size 16) Fix this by just assigning by using explicit casts for each checked case. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reported-by: syzbot+a448cda4dba2dac50de5@syzkaller.appspotmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:26:14 UTC
8e25c02 Jason A. Donenfeld 16 September 2022, 14:37:39 UTC wireguard: selftests: do not install headers on UML Since 1b620d539ccc ("kbuild: disable header exports for UML in a straightforward way"), installing headers fails on UML, so just disable installing them, since they're not needed anyway on the architecture. Fixes: b438b3b8d6e6 ("wireguard: selftests: support UML") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:26:14 UTC
684dec3 Jason A. Donenfeld 16 September 2022, 14:37:38 UTC wireguard: ratelimiter: disable timings test by default A previous commit tried to make the ratelimiter timings test more reliable but in the process made it less reliable on other configurations. This is an impossible problem to solve without increasingly ridiculous heuristics. And it's not even a problem that actually needs to be solved in any comprehensive way, since this is only ever used during development. So just cordon this off with a DEBUG_ ifdef, just like we do for the trie's randomized tests, so it can be enabled while hacking on the code, and otherwise disabled in CI. In the process we also revert 151c8e499f47. Fixes: 151c8e499f47 ("wireguard: ratelimiter: use hrtimer in selftest") Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:26:13 UTC
589c6ed Íñigo Huguet 15 September 2022, 14:19:58 UTC sfc/siena: fix null pointer dereference in efx_hard_start_xmit Like in previous patch for sfc, prevent potential (but unlikely) NULL pointer dereference. Fixes: 12804793b17c ("sfc: decouple TXQ type from label") Reported-by: Tianhao Zhao <tizhao@redhat.com> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Link: https://lore.kernel.org/r/20220915141958.16458-1-ihuguet@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:21:28 UTC
974bb79 Íñigo Huguet 15 September 2022, 14:16:53 UTC sfc/siena: fix TX channel offset when using legacy interrupts As in previous commit for sfc, fix TX channels offset when efx_siena_separate_tx_channels is false (the default) Fixes: 25bde571b4a8 ("sfc/siena: fix wrong tx channel offset with efx_separate_tx_channels") Reported-by: Tianhao Zhao <tizhao@redhat.com> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Link: https://lore.kernel.org/r/20220915141653.15504-1-ihuguet@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 18:21:13 UTC
60891ec Linus Torvalds 20 September 2022, 17:23:24 UTC Merge tag 'for-6.0-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - two fixes for hangs in the umount sequence where threads depend on each other and the work must be finished in the right order - in zoned mode, wait for flushing all block group metadata IO before finishing the zone * tag 'for-6.0-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: zoned: wait for extent buffer IOs before finishing a zone btrfs: fix hang during unmount when stopping a space reclaim worker btrfs: fix hang during unmount when stopping block group reclaim worker 20 September 2022, 17:23:24 UTC
84a3193 Linus Torvalds 20 September 2022, 17:08:37 UTC Merge tag 'fs.fixes.v6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping Pull vfs fix from Christian Brauner: "Beginning of the merge window we introduced the vfs{g,u}id_t types in b27c82e12965 ("attr: port attribute changes to new types") and changed various codepaths over including chown_common(). When userspace passes -1 for an ownership change the ownership fields in struct iattr stay uninitialized. Usually this is fine because any code making use of any fields in struct iattr must check the ->ia_valid field whether the value of interest has been initialized. That's true for all struct iattr passing code. However, over the course of the last year with more heavy use of KMSAN we found quite a few places that got this wrong. A recent one I fixed was 3cb6ee991496 ("9p: only copy valid iattrs in 9P2000.L setattr implementation"). But we also have LSM hooks. Actually we have two. The first one is security_inode_setattr() in notify_change() which does the right thing and passes the full struct iattr down to LSMs and thus LSMs can check whether it is initialized. But then we also have security_path_chown() which passes down a path argument and the target ownership as the filesystem would see it. For the latter we now generate the target values based on struct iattr and pass it down. However, when userspace passes -1 then struct iattr isn't initialized. This patch simply initializes ->ia_vfs{g,u}id with INVALID_VFS{G,U}ID so the hook continue to see invalid ownership when -1 is passed from userspace. The only LSM that cares about the actual values is Tomoyo. The vfs codepaths don't look at these fields without ->ia_valid being set so there's no harm in initializing ->ia_vfs{g,u}id. Arguably this is also safer since we can't end up copying valid ownership values when invalid ownership values should be passed. This only affects mainline. No kernel has been released with this and thus no backport is needed. The commit is thus marked with a Fixes: tag but annotated with "# mainline only" (I didn't quite remember what Greg said about how to tell stable autoselect to not bother with fixes for mainline only)" * tag 'fs.fixes.v6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping: open: always initialize ownership fields 20 September 2022, 17:08:37 UTC
7da5b13 Guilherme G. Piccoli 09 September 2022, 19:42:14 UTC efi: efibc: Guard against allocation failure There is a single kmalloc in this driver, and it's not currently guarded against allocation failure. Do it here by just bailing-out the reboot handler, in case this tentative allocation fails. Fixes: 416581e48679 ("efi: efibc: avoid efivar API for setting variables") Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 20 September 2022, 16:42:55 UTC
f489921 Linus Torvalds 20 September 2022, 15:38:55 UTC Merge tag 'execve-v6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull execve reverts from Kees Cook: "The recent work to support time namespace unsharing turns out to have some undesirable corner cases, so rather than allowing the API to stay exposed for another release, it'd be best to remove it ASAP, with the replacement getting another cycle of testing. Nothing is known to use this yet, so no userspace breakage is expected. For more details, see: https://lore.kernel.org/lkml/ed418e43ad28b8688cfea2b7c90fce1c@ispras.ru Summary: - Remove the recent 'unshare time namespace on vfork+exec' feature (Andrei Vagin)" * tag 'execve-v6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: Revert "fs/exec: allow to unshare a time namespace on vfork+exec" Revert "selftests/timens: add a test for vfork+exit" 20 September 2022, 15:38:55 UTC
d547c1b Tetsuo Handa 14 September 2022, 09:51:54 UTC net: clear msg_get_inq in __get_compat_msghdr() syzbot is still complaining uninit-value in tcp_recvmsg(), for commit 1228b34c8d0ecf6d ("net: clear msg_get_inq in __sys_recvfrom() and __copy_msghdr_from_user()") missed that __get_compat_msghdr() is called instead of copy_msghdr_from_user() when MSG_CMSG_COMPAT is specified. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: 1228b34c8d0ecf6d ("net: clear msg_get_inq in __sys_recvfrom() and __copy_msghdr_from_user()") Reviewed-by: Jens Axboe <axboe@kernel.dk> Link: https://lore.kernel.org/r/d06d0f7f-696c-83b4-b2d5-70b5f2730a37@I-love.SAKURA.ne.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 15:23:20 UTC
68fe503 Jakub Kicinski 20 September 2022, 15:22:20 UTC Merge branch 'ipmr-always-call-ip-6-_mr_forward-from-rcu-read-side-critical-section' Ido Schimmel says: ==================== ipmr: Always call ip{,6}_mr_forward() from RCU read-side critical section Patch #1 fixes a bug in ipmr code. Patch #2 adds corresponding test cases. ==================== Link: https://lore.kernel.org/r/20220914075339.4074096-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 15:22:20 UTC
2b5a8c8 Ido Schimmel 14 September 2022, 07:53:39 UTC selftests: forwarding: Add test cases for unresolved multicast routes Add IPv4 and IPv6 test cases for unresolved multicast routes, testing that queued packets are forwarded after installing a matching (S, G) route. The test cases can be used to reproduce the bugs fixed in "ipmr: Always call ip{,6}_mr_forward() from RCU read-side critical section". Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 15:22:15 UTC
b07a9b2 Ido Schimmel 14 September 2022, 07:53:38 UTC ipmr: Always call ip{,6}_mr_forward() from RCU read-side critical section These functions expect to be called from RCU read-side critical section, but this only happens when invoked from the data path via ip{,6}_mr_input(). They can also be invoked from process context in response to user space adding a multicast route which resolves a cache entry with queued packets [1][2]. Fix by adding missing rcu_read_lock() / rcu_read_unlock() in these call paths. [1] WARNING: suspicious RCU usage 6.0.0-rc3-custom-15969-g049d233c8bcc-dirty #1387 Not tainted ----------------------------- net/ipv4/ipmr.c:84 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by smcrouted/246: #0: ffffffff862389b0 (rtnl_mutex){+.+.}-{3:3}, at: ip_mroute_setsockopt+0x11c/0x1420 stack backtrace: CPU: 0 PID: 246 Comm: smcrouted Not tainted 6.0.0-rc3-custom-15969-g049d233c8bcc-dirty #1387 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x91/0xb9 vif_dev_read+0xbf/0xd0 ipmr_queue_xmit+0x135/0x1ab0 ip_mr_forward+0xe7b/0x13d0 ipmr_mfc_add+0x1a06/0x2ad0 ip_mroute_setsockopt+0x5c1/0x1420 do_ip_setsockopt+0x23d/0x37f0 ip_setsockopt+0x56/0x80 raw_setsockopt+0x219/0x290 __sys_setsockopt+0x236/0x4d0 __x64_sys_setsockopt+0xbe/0x160 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [2] WARNING: suspicious RCU usage 6.0.0-rc3-custom-15969-g049d233c8bcc-dirty #1387 Not tainted ----------------------------- net/ipv6/ip6mr.c:69 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by smcrouted/246: #0: ffffffff862389b0 (rtnl_mutex){+.+.}-{3:3}, at: ip6_mroute_setsockopt+0x6b9/0x2630 stack backtrace: CPU: 1 PID: 246 Comm: smcrouted Not tainted 6.0.0-rc3-custom-15969-g049d233c8bcc-dirty #1387 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x91/0xb9 vif_dev_read+0xbf/0xd0 ip6mr_forward2.isra.0+0xc9/0x1160 ip6_mr_forward+0xef0/0x13f0 ip6mr_mfc_add+0x1ff2/0x31f0 ip6_mroute_setsockopt+0x1825/0x2630 do_ipv6_setsockopt+0x462/0x4440 ipv6_setsockopt+0x105/0x140 rawv6_setsockopt+0xd8/0x690 __sys_setsockopt+0x236/0x4d0 __x64_sys_setsockopt+0xbe/0x160 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: ebc3197963fc ("ipmr: add rcu protection over (struct vif_device)->dev") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 15:22:15 UTC
cf412ec Alex Elder 13 September 2022, 20:46:02 UTC net: ipa: properly limit modem routing table use IPA can route packets between IPA-connected entities. The AP and modem are currently the only such entities supported, and no routing is required to transfer packets between them. The number of entries in each routing table is fixed, and defined at initialization time. Some of these entries are designated for use by the modem, and the rest are available for the AP to use. The AP sends a QMI message to the modem which describes (among other things) information about routing table memory available for the modem to use. Currently the QMI initialization packet gives wrong information in its description of routing tables. What *should* be supplied is the maximum index that the modem can use for the routing table memory located at a given location. The current code instead supplies the total *number* of routing table entries. Furthermore, the modem is granted the entire table, not just the subset it's supposed to use. This patch fixes this. First, the ipa_mem_bounds structure is generalized so its "end" field can be interpreted either as a final byte offset, or a final array index. Second, the IPv4 and IPv6 (non-hashed and hashed) table information fields in the QMI ipa_init_modem_driver_req structure are changed to be ipa_mem_bounds rather than ipa_mem_array structures. Third, we set the "end" value for each routing table to be the last index, rather than setting the "count" to be the number of indices. Finally, instead of allowing the modem to use all of a routing table's memory, it is limited to just the portion meant to be used by the modem. In all versions of IPA currently supported, that is IPA_ROUTE_MODEM_COUNT (8) entries. Update a few comments for clarity. Fixes: 530f9216a9537 ("soc: qcom: ipa: AP/modem communications") Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20220913204602.1803004-1-elder@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 15:11:13 UTC
1c48709 Liang He 13 September 2022, 12:56:59 UTC of: mdio: Add of_node_put() when breaking out of for_each_xx In of_mdiobus_register(), we should call of_node_put() for 'child' escaped out of for_each_available_child_of_node(). Fixes: 66bdede495c7 ("of_mdio: Fix broken PHY IRQ in case of probe deferral") Co-developed-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Liang He <windhl@126.com> Link: https://lore.kernel.org/r/20220913125659.3331969-1-windhl@126.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 14:32:09 UTC
d119888 Chris Wilson 16 September 2022, 09:24:03 UTC drm/i915/gem: Really move i915_gem_context.link under ref protection i915_perf assumes that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration. However, this requires that we do not remove the context from the list until after we drop the final reference and release the struct. If, as currently, we remove the context from the list during context_close(), the link.next pointer may be poisoned while we are holding the context reference and cause a GPF: [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180 [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202 [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000 [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68 [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860 [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000 [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0 [ 4070.575029] Call Trace: [ 4070.575033] <TASK> [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915] [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] [ 4070.575224] ? asm_common_interrupt+0x1e/0x40 [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575290] drm_ioctl_kernel+0x85/0x110 [ 4070.575296] ? update_load_avg+0x5f/0x5e0 [ 4070.575302] drm_ioctl+0x1d3/0x370 [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915] [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0 [ 4070.575451] ? __do_softirq+0xaa/0x1d2 [ 4070.575456] do_syscall_64+0x35/0x80 [ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 4070.575467] RIP: 0033:0x7f1ed5c10397 [ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48 [ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397 [ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006 [ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005 [ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a [ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0 [ 4070.575505] </TASK> [ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E) [ 4070.575549] ---[ end trace 0000000000000000 ]--- v3: fix incorrect syntax of spin_lock() replacing spin_lock_irqsave() v2: irqsave not required in a worker, neither conversion to irq safe elsewhere (Tvrtko), - perf: it's safe to call gen8_configure_context() even if context has been closed, no need to check, - drop unrelated cleanup (Andi, Tvrtko) Reported-by: Mark Janes <mark.janes@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/6222 References: a4e7ccdac38e ("drm/i915: Move context management under GEM") Fixes: f8246cf4d9a9 ("drm/i915/gem: Drop free_work for GEM contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916092403.201355-3-janusz.krzysztofik@linux.intel.com (cherry picked from commit ad3aa7c31efa5a09b0dba42e66cfdf77e0db7dc2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> 20 September 2022, 14:19:05 UTC
5ce8f74 Janusz Krzysztofik 16 September 2022, 09:24:02 UTC drm/i915/gem: Flush contexts on driver release Due to i915_perf assuming that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration, we need to defer removal of the context from the list until last reference to the context is put. However, there is a risk of triggering kernel warning on contexts list not empty at driver release time if we deleagate that task to a worker for i915_gem_context_release_work(), unless that work is flushed first. Unfortunately, it is not flushed on driver release. Fix it. Instead of additionally calling flush_workqueue(), either directly or via a new dedicated wrapper around it, replace last call to i915_gem_drain_freed_objects() with existing i915_gem_drain_workqueue() that performs both tasks. Fixes: 75eefd82581f ("drm/i915: Release i915_gem_context from a worker") Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: stable@kernel.org # v5.16+ Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916092403.201355-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 1cec34442408a77ba5396b19725fed2c398005c3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> 20 September 2022, 14:19:01 UTC
4c66a32 Christoph Hellwig 19 September 2022, 14:40:49 UTC Revert "block: freeze the queue earlier in del_gendisk" This reverts commit a09b314005f3a0956ebf56e01b3b80339df577cc. Dusty Mabe reported consistent hang during CoreOS shutdown with a MD RAID1 setup. Although apparently similar hangs happened before, and this patch most likely is not the root cause it made it much more severe. Revert it until we can figure out what is going on with the md driver. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220919144049.978907-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> 20 September 2022, 14:15:44 UTC
ab637d4 Linus Walleij 15 September 2022, 20:32:54 UTC gpio: ftgpio010: Make irqchip immutable This turns the FTGPIO010 irqchip immutable. Tested on the D-Link DIR-685. Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> 20 September 2022, 14:10:53 UTC
02743c4 Andy Shevchenko 20 September 2022, 13:30:31 UTC gpio: mockup: Fix potential resource leakage when register a chip If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path. Fixes: 6fda593f3082 ("gpio: mockup: Convert to use software nodes") Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> 20 September 2022, 14:07:15 UTC
b7df41a Bartosz Golaszewski 20 September 2022, 07:18:41 UTC gpio: mockup: fix NULL pointer dereference when removing debugfs We now remove the device's debugfs entries when unbinding the driver. This now causes a NULL-pointer dereference on module exit because the platform devices are unregistered *after* the global debugfs directory has been recursively removed. Fix it by unregistering the devices first. Fixes: 303e6da99429 ("gpio: mockup: remove gpio debugfs when remove device") Cc: Wei Yongjun <weiyongjun1@huawei.com> Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> 20 September 2022, 14:06:42 UTC
db4192a Cong Wang 12 September 2022, 17:35:53 UTC tcp: read multiple skbs in tcp_read_skb() Before we switched to ->read_skb(), ->read_sock() was passed with desc.count=1, which technically indicates we only read one skb per ->sk_data_ready() call. However, for TCP, this is not true. TCP at least has sk_rcvlowat which intentionally holds skb's in receive queue until this watermark is reached. This means when ->sk_data_ready() is invoked there could be multiple skb's in the queue, therefore we have to read multiple skbs in tcp_read_skb() instead of one. Fixes: 965b57b469a5 ("net: Introduce a new proto_ops ->read_skb()") Reported-by: Peilin Ye <peilin.ye@bytedance.com> Cc: John Fastabend <john.fastabend@gmail.com> Cc: Jakub Sitnicki <jakub@cloudflare.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20220912173553.235838-1-xiyou.wangcong@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 20 September 2022, 12:47:21 UTC
79764ec Takashi Iwai 20 September 2022, 11:39:29 UTC Revert "ALSA: usb-audio: Split endpoint setups for hw_params and prepare" This reverts commit ff878b408a03bef5d610b7e2302702e16a53636e. Unfortunately the recent fix seems bringing another regressions with PulseAudio / pipewire, at least for Steinberg and MOTU devices. As a temporary solution, do a straight revert. The issue for Android will be revisited again later by another different fix (if any). Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216500 Link: https://lore.kernel.org/r/20220920113929.25162-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 20 September 2022, 11:40:18 UTC
90fdd1c Paolo Abeni 20 September 2022, 10:18:08 UTC Merge branch 'revert-fec-ptp-changes' Francesco Dolcini says: ==================== Revert fec PTP changes Revert the last 2 FEC PTP changes from Csókás Bence, they are causing multiple issues and we are at 6.0-rc5. ==================== Link: https://lore.kernel.org/r/20220912070143.98153-1-francesco.dolcini@toradex.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 20 September 2022, 10:18:08 UTC
01b825f Francesco Dolcini 12 September 2022, 07:01:43 UTC Revert "net: fec: Use a spinlock to guard `fep->ptp_clk_on`" This reverts commit b353b241f1eb9b6265358ffbe2632fdcb563354f, this is creating multiple issues, just not ready to be merged yet. Link: https://lore.kernel.org/all/CAHk-=wj1obPoTu1AHj9Bd_BGYjdjDyPP+vT5WMj8eheb3A9WHw@mail.gmail.com/ Link: https://lore.kernel.org/all/20220907143915.5w65kainpykfobte@pengutronix.de/ Fixes: b353b241f1eb ("net: fec: Use a spinlock to guard `fep->ptp_clk_on`") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 20 September 2022, 10:16:58 UTC
7b15515 Francesco Dolcini 12 September 2022, 07:01:42 UTC Revert "fec: Restart PPS after link state change" This reverts commit f79959220fa5fbda939592bf91c7a9ea90419040, this is creating multiple issues, just not ready to be merged yet. Link: https://lore.kernel.org/all/20220905180542.GA3685102@roeck-us.net/ Link: https://lore.kernel.org/all/CAHk-=wj1obPoTu1AHj9Bd_BGYjdjDyPP+vT5WMj8eheb3A9WHw@mail.gmail.com/ Fixes: f79959220fa5 ("fec: Restart PPS after link state change") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 20 September 2022, 10:16:58 UTC
807e5ed Rakesh Sankaranarayanan 12 September 2022, 05:12:28 UTC net: dsa: microchip: lan937x: fix maximum frame length check Maximum frame length check is enabled in lan937x switch on POR, But it is found to be disabled on driver during port setup operation. Due to this, packets are not dropped when transmitted with greater than configured value. For testing, setup made for lan1->lan2 transmission and configured lan1 interface with a frame length (less than 1500 as mentioned in documentation) and transmitted packets with greater than configured value. Expected no packets at lan2 end, but packets observed at lan2. Based on the documentation, packets should get discarded if the actual packet length doesn't match the frame length configured. Frame length check should be disabled only for cascaded ports due to tailtags. This feature was disabled on ksz9477 series due to ptp issue, which is not in lan937x series. But since lan937x took ksz9477 as base, frame length check disabled here as well. Patch added to remove this portion from port setup so that maximum frame length check will be active for normal ports. Fixes: 55ab6ffaf378 ("net: dsa: microchip: add DSA support for microchip LAN937x") Signed-off-by: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com> Link: https://lore.kernel.org/r/20220912051228.1306074-1-rakesh.sankaranarayanan@microchip.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 20 September 2022, 10:01:51 UTC
f52d74b Tetsuo Handa 19 September 2022, 11:05:12 UTC open: always initialize ownership fields Beginning of the merge window we introduced the vfs{g,u}id_t types in b27c82e12965 ("attr: port attribute changes to new types") and changed various codepaths over including chown_common(). During that change we forgot to account for the case were the passed ownership value is -1. In this case the ownership fields in struct iattr aren't initialized but we rely on them being initialized by the time we generate the ownership to pass down to the LSMs. All the major LSMs don't care about the ownership values at all. Only Tomoyo uses them and so it took a while for syzbot to unearth this issue. Fix this by initializing the ownership fields and do it within the retry_deleg block. While notify_change() doesn't alter the ownership fields currently we shouldn't rely on it. Since no kernel has been released with these changes this does not needed to be backported to any stable kernels. [Christian Brauner (Microsoft) <brauner@kernel.org>] * rewrote commit message * use INVALID_VFS{G,U}ID macros Fixes: b27c82e12965 ("attr: port attribute changes to new types") # mainline only Reported-and-tested-by: syzbot+541e21dcc32c4046cba9@syzkaller.appspotmail.com Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Seth Forshee (DigitalOcean) <sforshee@kernel.org> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org> 20 September 2022, 09:57:57 UTC
d8a79c0 Randy Dunlap 31 May 2022, 02:55:57 UTC drm/hisilicon: Add depends on MMU The Kconfig symbol depended on MMU but was dropped by the commit acad3fe650a5 ("drm/hisilicon: Removed the dependency on the mmu") because it already had as a dependency ARM64 that already selects MMU. But later, commit a0f25a6bb319 ("drm/hisilicon/hibmc: Allow to be built if COMPILE_TEST is enabled") allowed the driver to be built for non-ARM64 when COMPILE_TEST is set but that could lead to unmet direct dependencies and linking errors. Prevent a kconfig warning when MMU is not enabled by making DRM_HISI_HIBMC depend on MMU. WARNING: unmet direct dependencies detected for DRM_TTM Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n] Selected by [m]: - DRM_TTM_HELPER [=m] && HAS_IOMEM [=y] && DRM [=m] - DRM_HISI_HIBMC [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && (ARM64 || COMPILE_TEST [=y]) Fixes: acad3fe650a5 ("drm/hisilicon: Removed the dependency on the mmu") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Tian Tao <tiantao6@hisilicon.com> Cc: John Stultz <jstultz@google.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220531025557.29593-1-rdunlap@infradead.org 20 September 2022, 09:15:09 UTC
5415bec Thomas Zimmermann 15 September 2022, 15:03:48 UTC drm/mgag200: Force 32 bpp on the console G200ER does not seem to support 24 bpp, so force the console to use 32 bpp. The problem got introduced when commit 73f54d5d9682 ("drm/mgag200: Remove special case for G200SE with <2 MiB") changed the preferred color depth from 32 bit to 24 bit. A setting of 24 is the correct color depth, but G200ER doesn't seem to be able to use the respective RGB888 color format. Using 24-bit color with forced 32 bpp works around the problem. Reported-by: Wang Yugui <wangyugui@e16-tech.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Wang Yugui <wangyugui@e16-tech.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Fixes: 73f54d5d9682 ("drm/mgag200: Remove special case for G200SE with <2 MiB") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220915150348.31504-1-tzimmermann@suse.de 20 September 2022, 07:20:23 UTC
8ccac4e Shailend Chand 13 September 2022, 00:09:01 UTC gve: Fix GFP flags when allocing pages Use GFP_ATOMIC when allocating pages out of the hotpath, continue to use GFP_KERNEL when allocating pages during setup. GFP_KERNEL will allow blocking which allows it to succeed more often in a low memory enviornment but in the hotpath we do not want to allow the allocation to block. Fixes: 9b8dd5e5ea48b ("gve: DQO: Add RX path") Signed-off-by: Shailend Chand <shailend@google.com> Signed-off-by: Jeroen de Borst <jeroendb@google.com> Link: https://lore.kernel.org/r/20220913000901.959546-1-jeroendb@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 01:31:06 UTC
ae8ffba Vadim Fedorenko 15 September 2022, 23:49:32 UTC bnxt_en: fix flags to check for supported fw version The warning message of unsupported FW appears every time RX timestamps are disabled on the interface. The patch fixes the flags to correct set for the check. Fixes: 66ed81dcedc6 ("bnxt_en: Enable packet timestamping for all RX packets") Cc: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru> Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20220915234932.25497-1-vfedorenko@novek.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 01:22:06 UTC
094cc3b Jakub Kicinski 20 September 2022, 01:17:22 UTC Merge tag 'wireless-2022-09-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.0 Late stage fixes for v6.0. Temporarily mark iwlwifi's mei code broken as it breaks suspend for iwd users and also don't spam nss trimming messages. mt76 has fixes for aggregation sequence numbers and a regression related to the VHT extended NSS BW feature. * tag 'wireless-2022-09-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: mt76: fix 5 GHz connection regression on mt76x0/mt76x2 wifi: mt76: fix reading current per-tid starting sequence number for aggregation wifi: iwlwifi: Mark IWLMEI as broken wifi: iwlwifi: don't spam logs with NSS>2 messages ==================== Link: https://lore.kernel.org/r/20220919105003.1EAE7C433B5@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 01:17:22 UTC
0ee513c Jakub Kicinski 20 September 2022, 01:13:43 UTC Merge tag 'batadv-net-pullrequest-20220916' of git://git.open-mesh.org/linux-merge Simon Wunderlich says: ==================== Here is a batman-adv bugfix: - Fix hang up with small MTU hard-interface, by Shigeru Yoshida * tag 'batadv-net-pullrequest-20220916' of git://git.open-mesh.org/linux-merge: batman-adv: Fix hang up with small MTU hard-interface ==================== Link: https://lore.kernel.org/r/20220916160931.1412407-1-sw@simonwunderlich.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 01:13:44 UTC
0a242eb Íñigo Huguet 14 September 2022, 11:11:35 UTC sfc: fix null pointer dereference in efx_hard_start_xmit Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] Fixes: 12804793b17c ("sfc: decouple TXQ type from label") Reported-by: Tianhao Zhao <tizhao@redhat.com> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/20220914111135.21038-1-ihuguet@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 01:09:55 UTC
f232af4 Íñigo Huguet 14 September 2022, 10:36:48 UTC sfc: fix TX channel offset when using legacy interrupts In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] Fixes: c308dfd1b43e ("sfc: fix wrong tx channel offset with efx_separate_tx_channels") Reported-by: Tianhao Zhao <tizhao@redhat.com> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/20220914103648.16902-1-ihuguet@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 01:09:43 UTC
95b9fd7 Jakub Kicinski 20 September 2022, 01:01:04 UTC Merge tag 'for-net-2022-09-09' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fix HCIGETDEVINFO regression * tag 'for-net-2022-09-09' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: Fix HCIGETDEVINFO regression ==================== Link: https://lore.kernel.org/r/20220909201642.3810565-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 20 September 2022, 01:01:04 UTC
5e69163 Lorenzo Bianconi 13 September 2022, 13:03:05 UTC net: ethernet: mtk_eth_soc: enable XDP support just for MT7986 SoC Disable page_pool/XDP support for MT7621 SoC in order fix a regression introduce adding XDP for MT7986 SoC. There is no a real use case for XDP on MT7621 since it is a low-end cpu. Moreover this patch reduces the memory footprint. Tested-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Fixes: 23233e577ef9 ("net: ethernet: mtk_eth_soc: rely on page_pool for single page buffers") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/2bf31e27b888c43228b0d84dd2ef5033338269e2.1663074002.git.lorenzo@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 19 September 2022, 23:30:54 UTC
6fd2c68 Haiyang Zhang 11 September 2022, 20:40:05 UTC net: mana: Add rmb after checking owner bits Per GDMA spec, rmb is necessary after checking owner_bits, before reading EQ or CQ entries. Add rmb in these two places to comply with the specs. Cc: stable@vger.kernel.org Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Reported-by: Sinan Kaya <Sinan.Kaya@microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Link: https://lore.kernel.org/r/1662928805-15861-1-git-send-email-haiyangz@microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 19 September 2022, 23:23:19 UTC
6fb2dbd Jeroen de Borst 13 September 2022, 18:53:19 UTC MAINTAINERS: gve: update developers Updating active developers. Signed-off-by: Jeroen de Borst <jeroendb@google.com> Link: https://lore.kernel.org/r/20220913185319.1061909-1-jeroendb@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 19 September 2022, 22:01:47 UTC
back to top