ab9c13a | Christophe JAILLET | 23 August 2021, 21:30:39 UTC | parisc/parport_gsc: switch from 'pci_' to 'dma_' API The wrappers in include/linux/pci-dma-compat.h should go away. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:25 UTC |
6ef4661 | Masahiro Yamada | 11 August 2021, 16:41:16 UTC | parisc: move core-y in arch/parisc/Makefile to arch/parisc/Kbuild Use obj-y to clean up Makefile. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:25 UTC |
0c38502 | Christophe JAILLET | 22 August 2021, 20:29:01 UTC | parisc: switch from 'pci_' to 'dma_' API The wrappers in include/linux/pci-dma-compat.h should go away. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:25 UTC |
87875c1 | Uwe Kleine-König | 07 August 2021, 09:19:27 UTC | parisc: Make struct parisc_driver::remove() return void The caller of this function (parisc_driver_remove() in arch/parisc/kernel/drivers.c) ignores the return value, so better don't return any value at all to not wake wrong expectations in driver authors. The only function that could return a non-zero value before was ipmi_parisc_remove() which returns the return value of ipmi_si_remove_by_dev(). Make this function return void, too, as for all other callers the value is ignored, too. Also fold in a small checkpatch fix for: WARNING: Unnecessary space before function pointer arguments + void (*remove) (struct parisc_device *dev); Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> (for drivers/input) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:25 UTC |
d220da0 | Masahiro Yamada | 24 August 2021, 15:48:20 UTC | parisc: remove unused arch/parisc/boot/install.sh and its phony target Parisc has two similar installation scripts: arch/parisc/install.sh arch/parisc/boot/install.sh The latter is never used because 'make ARCH=parisc install' always invokes the 'install' target in arch/parisc/Makefile. The target in arch/parisc/boot/Makefile is not used either. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:25 UTC |
7bf82eb | Matthew Wilcox (Oracle) | 15 July 2021, 13:46:12 UTC | parisc: Rename PMD_ORDER to PMD_TABLE_ORDER This is the order of the page table allocation, not the order of a PMD. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:25 UTC |
7f2dcc7 | Kees Cook | 18 August 2021, 03:18:09 UTC | parisc: math-emu: Avoid "fmt" macro collision The printk "fmt" macro was colliding. Rename like the others with a "bits" suffix. Fixes a build failure: arch/parisc/math-emu/decode_exc.c: In function 'decode_fpu': arch/parisc/math-emu/decode_exc.c:49:14: error: expected identifier before numeric constant 49 | #define fmt 11 /* bits 19 & 20 */ | ^~ ./include/linux/printk.h:379:6: note: in expansion of macro 'fmt' 379 | .fmt = __builtin_constant_p(_fmt) ? (_fmt) : NULL, \ | ^~~ ./include/linux/printk.h:417:3: note: in expansion of macro '__printk_index_emit' 417 | __printk_index_emit(_fmt, NULL, NULL); \ | ^~~~~~~~~~~~~~~~~~~ ./include/linux/printk.h:446:26: note: in expansion of macro 'printk_index_wrap' 446 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__) | ^~~~~~~~~~~~~~~~~ arch/parisc/math-emu/decode_exc.c:339:3: note: in expansion of macro 'printk' 339 | printk("%s(%d) Unknown FPU exception 0x%x\n", __FILE__, | ^~~~~~ Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: linux-parisc@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:24 UTC |
55b70ee | Helge Deller | 07 July 2021, 13:38:08 UTC | parisc: Increase size of gcc stack frame check parisc uses much bigger frames than other architectures, so increase the stack frame check value to avoid compiler warnings. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:24 UTC |
7e07b74 | Jinchao Wang | 26 June 2021, 10:20:52 UTC | parisc: Replace symbolic permissions with octal permissions Resolve following checkpatch issue, Replace symbolic permissions with octal permissions Signed-off-by: Jinchao Wang <wjc@cdjrlc.com> Signed-off-by: Helge Deller <deller@gmx.de> | 30 August 2021, 08:18:24 UTC |
7d2a07b | Linus Torvalds | 29 August 2021, 22:04:50 UTC | Linux 5.14 | 29 August 2021, 22:04:50 UTC |
90ac80d | Linus Torvalds | 29 August 2021, 19:52:17 UTC | Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fix from Stephen Boyd: "One hotfix for a NULL pointer deref in the Renesas usb clk driver" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: renesas: rcar-usb2-clock-sel: Fix kernel NULL pointer dereference | 29 August 2021, 19:52:17 UTC |
537b57b | Linus Torvalds | 29 August 2021, 17:54:14 UTC | Merge tag 'sched_urgent_for_v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Borislav Petkov: - Have get_push_task() check whether current has migration disabled and thus avoid useless invocations of the migration thread - Rework initialization flow so that all rq->core's are initialized, even of CPUs which have not been onlined yet, so that iterating over them all works as expected * tag 'sched_urgent_for_v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched: Fix get_push_task() vs migrate_disable() sched: Fix Core-wide rq->lock for uninitialized CPUs | 29 August 2021, 17:54:14 UTC |
f20a263 | Linus Torvalds | 29 August 2021, 17:47:02 UTC | Merge tag 'irq_urgent_for_v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Borislav Petkov: - Have msix_mask_all() check a global control which says whether MSI-X masking should be done and thus make it usable on Xen-PV too * tag 'irq_urgent_for_v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: PCI/MSI: Skip masking MSI-X on Xen PV | 29 August 2021, 17:47:02 UTC |
98d006e | Linus Torvalds | 29 August 2021, 17:36:32 UTC | Merge tag 'perf_urgent_for_v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Borislav Petkov: - Prevent the amd/power module from being removed while in use - Mark AMD IBS as not supporting content exclusion - Add a workaround for AMD erratum #1197 where IBS registers might not be restored properly after exiting CC6 state - Fix a potential truncation of a 32-bit variable due to shifting - Read the correct bits describing the number of configurable address ranges on Intel PT * tag 'perf_urgent_for_v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/amd/power: Assign pmu.module perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op perf/x86/amd/ibs: Work around erratum #1197 perf/x86/intel/uncore: Fix integer overflow on 23 bit left shift of a u32 perf/x86/intel/pt: Fix mask of num_address_ranges | 29 August 2021, 17:36:32 UTC |
072a276 | Linus Torvalds | 29 August 2021, 17:26:00 UTC | Merge tag 'x86_urgent_for_v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Fix build error on RHEL where -Werror=maybe-uninitialized is set. - Restore the firmware's IDT when calling EFI boot services and before ExitBootServices() has been called. This fixes a boot failure on what appears to be a tablet with 32-bit UEFI running a 64-bit kernel. * tag 'x86_urgent_for_v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/resctrl: Fix a maybe-uninitialized build warning treated as error x86/efi: Restore Firmware IDT before calling ExitBootServices() | 29 August 2021, 17:26:00 UTC |
f6a3308 | Helge Deller | 27 August 2021, 18:42:57 UTC | Revert "parisc: Add assembly implementations for memset, strlen, strcpy, strncpy and strcat" This reverts commit 83af58f8068ea3f7b3c537c37a30887bfa585069. It turns out that at least the assembly implementation for strncpy() was buggy. Revert the whole commit and return back to the default coding. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v5.4+ Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 29 August 2021, 17:13:32 UTC |
1669a94 | Adam Ford | 26 August 2021, 14:17:21 UTC | clk: renesas: rcar-usb2-clock-sel: Fix kernel NULL pointer dereference The probe was manually passing NULL instead of dev to devm_clk_hw_register. This caused a Unable to handle kernel NULL pointer dereference error. Fix this by passing 'dev'. Signed-off-by: Adam Ford <aford173@gmail.com> Fixes: a20a40a8bbc2 ("clk: renesas: rcar-usb2-clock-sel: Fix error handling in .probe()") Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Stephen Boyd <sboyd@kernel.org> | 29 August 2021, 04:29:36 UTC |
3f5ad13 | Linus Torvalds | 28 August 2021, 18:39:16 UTC | Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fix from James Bottomley: "A single fix for a race introduced by a fix that went into 5.14-rc5" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: core: Fix hang of freezing queue between blocking and running device | 28 August 2021, 18:39:16 UTC |
447e238 | Linus Torvalds | 28 August 2021, 18:32:16 UTC | Merge tag 'usb-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are a few tiny USB fixes for reported issues with some USB drivers. These fixes include: - gadget driver fixes for regressions - tcpm driver fix - dwc3 driver fixes - xhci renesas firmware loading fix, again. - usb serial option driver device id addition - usb serial ch341 revert for regression All all of these have been in linux-next with no reported problems" * tag 'usb-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: gadget: u_audio: fix race condition on endpoint stop usb: gadget: f_uac2: fixup feedback endpoint stop usb: typec: tcpm: Raise vdm_sm_running flag only when VDM SM is running usb: renesas-xhci: Prefer firmware loading on unknown ROM state usb: dwc3: gadget: Stop EP0 transfers during pullup disable usb: dwc3: gadget: Fix dwc3_calc_trbs_left() Revert "USB: serial: ch341: fix character loss at high transfer rates" USB: serial: option: add new VID/PID to support Fibocom FG150 | 28 August 2021, 18:32:16 UTC |
9f73eac | Linus Torvalds | 28 August 2021, 17:40:41 UTC | Merge tag 'powerpc-5.14-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Fix scv implicit soft-mask table for relocated (eg. kdump) kernels - Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCK, which was disabled due to a typo Thanks to Lukas Bulwahn, Nicholas Piggin, and Daniel Axtens. * tag 'powerpc-5.14-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/64s: Fix scv implicit soft-mask table for relocated kernels powerpc: Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCK | 28 August 2021, 17:40:41 UTC |
64b4fc4 | Linus Torvalds | 27 August 2021, 23:08:29 UTC | Merge tag 'block-5.14-2021-08-27' of git://git.kernel.dk/linux-block Pull block fixes from Jens Axboe: - Revert the mq-deadline priority handling, it's causing serious performance regressions. While experimental patches exists to fix this up, it's too late to do so now. Revert it and re-do it properly for 5.15 instead. - Fix a NULL vs IS_ERR() regression in this release (Dan) - Fix a mq-deadline accounting regression in this release (Bart) - Mark cryptoloop as deprecated. It's broken and dm-crypt fully supports it, and it's actively intefering with loop. Plan on removal for 5.16 (Christoph) * tag 'block-5.14-2021-08-27' of git://git.kernel.dk/linux-block: cryptoloop: add a deprecation warning pd: fix a NULL vs IS_ERR() check Revert "block/mq-deadline: Prioritize high-priority requests" mq-deadline: Fix request accounting | 27 August 2021, 23:08:29 UTC |
6f18b82 | Linus Torvalds | 27 August 2021, 22:59:00 UTC | Merge tag 'soc-fixes-5.14-4' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Just two trivial fixes from the reset driver tree, nothing else came up since the last soc fixes" * tag 'soc-fixes-5.14-4' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: reset: reset-zynqmp: Fixed the argument data type reset: RESET_MCHP_SPARX5 should depend on ARCH_SPARX5 | 27 August 2021, 22:59:00 UTC |
8f9d034 | Linus Torvalds | 27 August 2021, 19:18:09 UTC | Merge tag 'acpi-5.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Fix a regression introduced during this cycle that has been partially addressed by an earlier commit (Andy Shevchenko)" * tag 'acpi-5.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: media: ipu3-cio2: Drop reference on error path in cio2_bridge_connect_sensor() | 27 August 2021, 19:18:09 UTC |
c0006dc | Linus Torvalds | 27 August 2021, 19:06:51 UTC | Merge tag 'pm-5.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix two issues introduced during this cycle, one of which is a regression and the other one affects new code. Specifics: - Prevent the operating performance points (OPP) code from crashing when some entries in the table of required OPPs are set to error pointer values (Marijn Suijten) - Prevent the generic power domains (genpd) framework from incorrectly overriding the performance state of a device set by its driver while it is runtime-suspended or when runtime PM of it is disabled (Dmitry Osipenko)" * tag 'pm-5.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: domains: Improve runtime PM performance state handling opp: core: Check for pending links before reading required_opp pointers | 27 August 2021, 19:06:51 UTC |
425bec0 | David Hildenbrand | 25 August 2021, 10:24:15 UTC | virtio-mem: fix sleeping in RCU read side section in virtio_mem_online_page_cb() virtio_mem_set_fake_offline() might sleep now, and we call it under rcu_read_lock(). To fix it, simply move the rcu_read_unlock() further up, as we're done with the device. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 6cc26d77613a: "virtio-mem: use page_offline_(start|end) when setting PageOffline() Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: virtualization@lists.linux-foundation.org Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 27 August 2021, 18:39:36 UTC |
7ee5fd1 | Rafael J. Wysocki | 27 August 2021, 18:27:01 UTC | Merge branch 'pm-opp' * pm-opp: opp: core: Check for pending links before reading required_opp pointers | 27 August 2021, 18:27:01 UTC |
5a61b7a | Linus Torvalds | 27 August 2021, 18:04:57 UTC | Merge tag 'riscv-for-linus-5.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - device tree updates for the Microsemi Polarfire development kit that fix some mismatches between the u-boot and Linux enternet entries - ensure that the F register state is correctly reflected in core dumps * tag 'riscv-for-linus-5.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: dts: microchip: Add ethernet0 to the aliases node riscv: dts: microchip: Use 'local-mac-address' for emac1 riscv: Ensure the value of FP registers in the core dump file is up to date | 27 August 2021, 18:04:57 UTC |
1a6436f | Linus Torvalds | 27 August 2021, 16:52:48 UTC | Merge tag 'mmc-v5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC host fix from Ulf Hansson: - sdhci-iproc: Fix clock error for ACPI rpi's * tag 'mmc-v5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: Revert "mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711" | 27 August 2021, 16:52:48 UTC |
222013f | Christoph Hellwig | 27 August 2021, 16:32:50 UTC | cryptoloop: add a deprecation warning Support for cryptoloop has been officially marked broken and deprecated in favor of dm-crypt (which supports the same broken algorithms if needed) in Linux 2.6.4 (released in March 2004), and support for it has been entirely removed from losetup in util-linux 2.23 (released in April 2013). Add a warning and a deprecation schedule. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20210827163250.255325-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> | 27 August 2021, 16:44:54 UTC |
94606b8 | Linus Torvalds | 27 August 2021, 16:00:43 UTC | Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm Pull ARM fix from Russell King: "Resolve a Keystone 2 kernel mapping regression" * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9104/2: Fix Keystone 2 kernel mapping regression | 27 August 2021, 16:00:43 UTC |
885814a | Ulf Hansson | 27 August 2021, 14:30:36 UTC | Revert "mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711" This reverts commit 419dd626e357e89fc9c4e3863592c8b38cfe1571. It turned out that the change from the reverted commit breaks the ACPI based rpi's because it causes the 100Mhz max clock to be overridden to the return from sdhci_iproc_get_max_clock(), which is 0 because there isn't a OF/DT based clock device. Reported-by: Jeremy Linton <jeremy.linton@arm.com> Fixes: 419dd626e357 ("mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711") Acked-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> | 27 August 2021, 14:30:36 UTC |
068fdad | Jerome Brunet | 27 August 2021, 09:29:27 UTC | usb: gadget: u_audio: fix race condition on endpoint stop If the endpoint completion callback is call right after the ep_enabled flag is cleared and before usb_ep_dequeue() is call, we could do a double free on the request and the associated buffer. Fix this by clearing ep_enabled after all the endpoint requests have been dequeued. Fixes: 7de8681be2cd ("usb: gadget: u_audio: Free requests only after callback") Cc: stable <stable@vger.kernel.org> Reported-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20210827092927.366482-1-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 27 August 2021, 14:07:23 UTC |
75432ba | Jerome Brunet | 27 August 2021, 07:58:53 UTC | usb: gadget: f_uac2: fixup feedback endpoint stop When the uac2 function is stopped, there seems to be an issue reported on some platforms (Intel Merrifield at least) BUG: kernel NULL pointer dereference, address: 0000000000000008 ... RIP: 0010:dwc3_gadget_del_and_unmap_request+0x19/0xe0 ... Call Trace: dwc3_remove_requests.constprop.0+0x12f/0x170 __dwc3_gadget_ep_disable+0x7a/0x160 dwc3_gadget_ep_disable+0x3d/0xd0 usb_ep_disable+0x1c/0x70 u_audio_stop_capture+0x79/0x120 [u_audio] afunc_set_alt+0x73/0x80 [usb_f_uac2] composite_setup+0x224/0x1b90 [libcomposite] The issue happens only when the gadget is using the sync type "async", not "adaptive". This indicates that problem is coming from the feedback endpoint, which is only used with async synchronization mode. The problem is that request is freed regardless of usb_ep_dequeue(), which ends up badly if the request is not actually dequeued yet. Update the feedback endpoint free function to release the endpoint the same way it is done for the data endpoint, which takes care of the problem. Fixes: 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add feedback endpoint support") Reported-by: Ferry Toth <ftoth@exalondelft.nl> Tested-by: Ferry Toth <ftoth@exalondelft.nl> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20210827075853.266912-1-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 27 August 2021, 14:06:53 UTC |
3375dca | Dan Carpenter | 27 August 2021, 10:00:23 UTC | pd: fix a NULL vs IS_ERR() check blk_mq_alloc_disk() returns error pointers, it doesn't return NULL so correct the check. Fixes: 262d431f9000 ("pd: use blk_mq_alloc_disk and blk_cleanup_disk") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210827100023.GB9449@kili Signed-off-by: Jens Axboe <axboe@kernel.dk> | 27 August 2021, 13:45:48 UTC |
77dd114 | Linus Torvalds | 27 August 2021, 01:44:25 UTC | Merge tag 'drm-fixes-2021-08-27' of git://anongit.freedesktop.org/drm/drm Pull drm fixes from Dave Airlie: "Last set of fixes for 5.14, nothing major a couple of i915, couple of imx and a few amdgpu. All pretty small. i915: - Fix syncmap memory leak - Drop redundant display port debug print amdgpu: - Fix for pinning display buffers multiple times - Fix delayed work handling for GFXOFF - Fix build when CONFIG_SUSPEND is not set imx: - fix planar offset calculations - fix accidental partial revert" * tag 'drm-fixes-2021-08-27' of git://anongit.freedesktop.org/drm/drm: drm/i915/dp: Drop redundant debug print drm/i915: Fix syncmap memory leak drm/amdgpu: Fix build with missing pm_suspend_target_state module export drm/amdgpu: Cancel delayed work when GFXOFF is disabled drm/amdgpu: use the preferred pin domain after the check drm/imx: ipuv3-plane: fix accidental partial revert of 8 pixel alignment fix gpu: ipu-v3: Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats | 27 August 2021, 01:44:25 UTC |
9fe4f5a | Dave Airlie | 27 August 2021, 00:49:32 UTC | Merge tag 'imx-drm-fixes-2021-08-18' of git://git.pengutronix.de/pza/linux into drm-fixes drm/imx: imx-drm alignment and plane offset fixes Fix an accidental partial revert of commit 94dfec48fca7 ("drm/imx: Add 8 pixel alignment fix") and plane offset calculations for capture of non-aligned resolutions. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/85a41af99beb2c9e7d6020435a135bf9f205a5ff.camel@pengutronix.de | 27 August 2021, 00:49:53 UTC |
589744d | Dave Airlie | 27 August 2021, 00:24:07 UTC | Merge tag 'amd-drm-fixes-5.14-2021-08-25' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.14-2021-08-25: amdgpu: - Fix for pinning display buffers multiple times - Fix delayed work handling for GFXOFF - Fix build when CONFIG_SUSPEND is not set Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210826032658.4068-1-alexander.deucher@amd.com | 27 August 2021, 00:24:07 UTC |
4f33239 | Dave Airlie | 27 August 2021, 00:13:37 UTC | Merge tag 'drm-intel-fixes-2021-08-26' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix syncmap memory leak - Drop redundant display port debug print Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YSfSeHbyS5wBZtNJ@intel.com | 27 August 2021, 00:13:51 UTC |
1a519dc | Marek Marczykowski-Górecki | 26 August 2021, 17:03:42 UTC | PCI/MSI: Skip masking MSI-X on Xen PV When running as Xen PV guest, masking MSI-X is a responsibility of the hypervisor. The guest has no write access to the relevant BAR at all - when it tries to, it results in a crash like this: BUG: unable to handle page fault for address: ffffc9004069100c #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation RIP: e030:__pci_enable_msix_range.part.0+0x26b/0x5f0 e1000e_set_interrupt_capability+0xbf/0xd0 [e1000e] e1000_probe+0x41f/0xdb0 [e1000e] local_pci_probe+0x42/0x80 (...) The recently introduced function msix_mask_all() does not check the global variable pci_msi_ignore_mask which is set by XEN PV to bypass the masking of MSI[-X] interrupts. Add the check to make this function XEN PV compatible. Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210826170342.135172-1-marmarek@invisiblethingslab.com | 26 August 2021, 22:27:15 UTC |
73367f0 | Linus Torvalds | 26 August 2021, 20:26:40 UTC | Merge tag 'nfsd-5.14-1' of git://linux-nfs.org/~bfields/linux Pull nfsd fix from Bruce Fields: "This is a one-liner fix for a serious bug that can cause the server to become unresponsive to a client, so I think it's worth the last-minute inclusion for 5.14" * tag 'nfsd-5.14-1' of git://linux-nfs.org/~bfields/linux: SUNRPC: Fix XPT_BUSY flag leakage in svc_handle_xprt()... | 26 August 2021, 20:26:40 UTC |
8a2cb8b | Linus Torvalds | 26 August 2021, 20:20:22 UTC | Merge tag 'net-5.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Networking fixes, including fixes from can and bpf. Closing three hw-dependent regressions. Any fixes of note are in the 'old code' category. Nothing blocking release from our perspective. Current release - regressions: - stmmac: revert "stmmac: align RX buffers" - usb: asix: ax88772: move embedded PHY detection as early as possible - usb: asix: do not call phy_disconnect() for ax88178 - Revert "net: really fix the build...", from Kalle to fix QCA6390 Current release - new code bugs: - phy: mediatek: add the missing suspend/resume callbacks Previous releases - regressions: - qrtr: fix another OOB Read in qrtr_endpoint_post - stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings Previous releases - always broken: - inet: use siphash in exception handling - ip_gre: add validation for csum_start - bpf: fix ringbuf helper function compatibility - rtnetlink: return correct error on changing device netns - e1000e: do not try to recover the NVM checksum on Tiger Lake" * tag 'net-5.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (43 commits) Revert "net: really fix the build..." net: hns3: fix get wrong pfc_en when query PFC configuration net: hns3: fix GRO configuration error after reset net: hns3: change the method of getting cmd index in debugfs net: hns3: fix duplicate node in VLAN list net: hns3: fix speed unknown issue in bond 4 net: hns3: add waiting time before cmdq memory is released net: hns3: clear hardware resource when loading driver net: fix NULL pointer reference in cipso_v4_doi_free rtnetlink: Return correct error on changing device netns net: dsa: hellcreek: Adjust schedule look ahead window net: dsa: hellcreek: Fix incorrect setting of GCL cxgb4: dont touch blocked freelist bitmap after free ipv4: use siphash instead of Jenkins in fnhe_hashfun() ipv6: use siphash in rt6_exception_hash() can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters net: usb: asix: ax88772: fix boolconv.cocci warnings net/sched: ets: fix crash when flipping from 'strict' to 'quantum' qede: Fix memset corruption net: stmmac: fix kernel panic due to NULL pointer dereference of buf->xdp ... | 26 August 2021, 20:20:22 UTC |
7b05bf7 | Jens Axboe | 26 August 2021, 18:59:44 UTC | Revert "block/mq-deadline: Prioritize high-priority requests" This reverts commit fb926032b3209300f9dc454a36b8299582ae545c. Zhen reports that this commit slows down mq-deadline on a 128 thread box, going from 258K IOPS to 170-180K. My testing shows that Optane gen2 IOPS goes from 2.3M IOPS to 1.2M IOPS on a 64 thread box. Looking in detail at the code, the main culprit here is needing to sum percpu counters in the dispatch hot path, leading to very high CPU utilization there. To make matters worse, the code currently needs to sum 2 percpu counters, and it does so in the most naive way of iterating possible CPUs _twice_. Since we're close to release, revert this commit and we can re-do it with regular per-priority counters instead for the 5.15 kernel. Link: https://lore.kernel.org/linux-block/20210826144039.2143-1-thunder.leizhen@huawei.com/ Reported-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> | 26 August 2021, 18:59:44 UTC |
1a6d80f | Linus Torvalds | 26 August 2021, 18:26:00 UTC | Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Will Deacon: "We received a report this week that the generic version of pfn_valid(), which we switched to this merge window in 16c9afc77660 ("arm64/mm: drop HAVE_ARCH_PFN_VALID"), interacts badly with dma_map_resource() due to the following check: /* Don't allow RAM to be mapped */ if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) return DMA_MAPPING_ERROR; Since the ongoing saga to determine the semantics of pfn_valid() is unlikely to be resolved this week (does it indicate valid memory, or just the presence of a struct page, or whether that struct page has been initialised?), just revert back to our old version of pfn_valid() for 5.14. Summary: - Fix dma_map_resource() by reverting back to old pfn_valid() code" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: Partially revert "arm64/mm: drop HAVE_ARCH_PFN_VALID" | 26 August 2021, 18:26:00 UTC |
97d8cc2 | Linus Torvalds | 26 August 2021, 18:18:30 UTC | Merge tag 'ceph-for-5.14-rc8' of git://github.com/ceph/ceph-client Pull ceph fixes from Ilya Dryomov: "Two memory management fixes for the filesystem" * tag 'ceph-for-5.14-rc8' of git://github.com/ceph/ceph-client: ceph: fix possible null-pointer dereference in ceph_mdsmap_decode() ceph: correctly handle releasing an embedded cap flush | 26 August 2021, 18:18:30 UTC |
9ebc275 | Kalle Valo | 26 August 2021, 17:28:16 UTC | Revert "net: really fix the build..." This reverts commit ce78ffa3ef1681065ba451cfd545da6126f5ca88. Wren and Nicolas reported that ath11k was failing to initialise QCA6390 Wi-Fi 6 device with error: qcom_mhi_qrtr: probe of mhi0_IPCR failed with error -22 Commit ce78ffa3ef16 ("net: really fix the build..."), introduced in v5.14-rc5, caused this regression in qrtr. Most likely all ath11k devices are broken, but I only tested QCA6390. Let's revert the broken commit so that ath11k works again. Reported-by: Wren Turkal <wt@penguintechs.org> Reported-by: Nicolas Schichan <nschichan@freebox.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210826172816.24478-1-kvalo@codeaurora.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 18:08:32 UTC |
9b49ceb | Linus Torvalds | 26 August 2021, 18:05:11 UTC | Merge tag 'for-5.14-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fix from David Sterba: "One more fix that I think qualifies for a late merge. It's a revert of a one-liner fix that meanwhile got backported to stable kernels and we got reports from users. The broken fix prevents creating compressed inline extents, which could be noticeable on space consumption. Technically it's a regression as the patch was merged in 5.14-rc1 but got propagated to several stable kernels and has higher exposure than a 'typical' development cycle bug" * tag 'for-5.14-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: Revert "btrfs: compression: don't try to compress if we don't have enough pages" | 26 August 2021, 18:05:11 UTC |
e681dcb | Sebastian Andrzej Siewior | 26 August 2021, 13:37:38 UTC | sched: Fix get_push_task() vs migrate_disable() push_rt_task() attempts to move the currently running task away if the next runnable task has migration disabled and therefore is pinned on the current CPU. The current task is retrieved via get_push_task() which only checks for nr_cpus_allowed == 1, but does not check whether the task has migration disabled and therefore cannot be moved either. The consequence is a pointless invocation of the migration thread which correctly observes that the task cannot be moved. Return NULL if the task has migration disabled and cannot be moved to another CPU. Fixes: a7c81556ec4d3 ("sched: Fix migrate_disable() vs rt/dl balancing") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20210826133738.yiotqbtdaxzjsnfj@linutronix.de | 26 August 2021, 17:02:00 UTC |
294c34e | Andy Shevchenko | 26 August 2021, 10:53:24 UTC | media: ipu3-cio2: Drop reference on error path in cio2_bridge_connect_sensor() The commit 71f642833284 ("ACPI: utils: Fix reference counting in for_each_acpi_dev_match()") moved adev assignment outside of error path and hence made acpi_dev_put(sensor->adev) a no-op. We still need to drop reference count on error path, and to achieve that, replace sensor->adev by locally assigned adev. Fixes: 71f642833284 ("ACPI: utils: Fix reference counting in for_each_acpi_dev_match()") Depends-on: fc68f42aa737 ("ACPI: fix NULL pointer dereference") Reported-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 26 August 2021, 16:52:30 UTC |
75da63b | Jakub Kicinski | 26 August 2021, 15:43:20 UTC | Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Alexei Starovoitov says: ==================== bpf 2021-08-26 We've added 1 non-merge commit during the last 1 day(s): 1) Fix ringbuf helper function compatibility, from Daniel. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Fix ringbuf helper function compatibility ==================== Link: https://lore.kernel.org/r/20210826153720.19083-1-alexei.starovoitov@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 15:44:38 UTC |
57f8178 | Jakub Kicinski | 26 August 2021, 14:24:20 UTC | Merge branch 'net-hns3-add-some-fixes-for-net' Guangbin Huang says: ==================== net: hns3: add some fixes for -net This series adds some fixes for the HNS3 ethernet driver. ==================== Link: https://lore.kernel.org/r/1629976921-43438-1-git-send-email-huangguangbin2@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 14:24:21 UTC |
8c1671e | Guangbin Huang | 26 August 2021, 11:22:01 UTC | net: hns3: fix get wrong pfc_en when query PFC configuration Currently, when query PFC configuration by dcbtool, driver will return PFC enable status based on TC. As all priorities are mapped to TC0 by default, if TC0 is enabled, then all priorities mapped to TC0 will be shown as enabled status when query PFC setting, even though some priorities have never been set. for example: $ dcb pfc show dev eth0 pfc-cap 4 macsec-bypass off delay 0 prio-pfc 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off $ dcb pfc set dev eth0 prio-pfc 0:on 1:on 2:on 3:on $ dcb pfc show dev eth0 pfc-cap 4 macsec-bypass off delay 0 prio-pfc 0:on 1:on 2:on 3:on 4:on 5:on 6:on 7:on To fix this problem, just returns user's PFC config parameter saved in driver. Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB feature") Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 14:24:17 UTC |
3462207 | Yufeng Mo | 26 August 2021, 11:22:00 UTC | net: hns3: fix GRO configuration error after reset The GRO configuration is enabled by default after reset. This is incorrect and should be restored to the user-configured value. So this restoration is added during reset initialization. Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 14:24:17 UTC |
55649d5 | Yufeng Mo | 26 August 2021, 11:21:59 UTC | net: hns3: change the method of getting cmd index in debugfs Currently, the cmd index is obtained in debugfs by comparing file names. However, this method may cause errors when processing more complex file names. So, change this method by saving cmd in private data and comparing it when getting cmd index in debugfs for optimization. Fixes: 5e69ea7ee2a6 ("net: hns3: refactor the debugfs process") Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 14:24:17 UTC |
94391fa | Guojia Liao | 26 August 2021, 11:21:58 UTC | net: hns3: fix duplicate node in VLAN list VLAN list should not be added duplicate VLAN node, otherwise it would cause "add failed" when restore VLAN from VLAN list, so this patch adds VLAN ID check before adding node into VLAN list. Fixes: c6075b193462 ("net: hns3: Record VF vlan tables") Signed-off-by: Guojia Liao <liaoguojia@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 14:24:17 UTC |
b15c072 | Yonglong Liu | 26 August 2021, 11:21:57 UTC | net: hns3: fix speed unknown issue in bond 4 In bond 4, when the link goes down and up repeatedly, the bond may get an unknown speed, and then this port can not work. The driver notify netif_carrier_on() before update the link state, when the bond receive carrier on, will query the speed of the port, if the query operation happens before updating the link state, will get an unknown speed. So need to notify netif_carrier_on() after update the link state. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 14:24:16 UTC |
a96d933 | Yufeng Mo | 26 August 2021, 11:21:56 UTC | net: hns3: add waiting time before cmdq memory is released After the cmdq registers are cleared, the firmware may take time to clear out possible left over commands in the cmdq. Driver must release cmdq memory only after firmware has completed processing of left over commands. Fixes: 232d0d55fca6 ("net: hns3: uninitialize command queue while unloading PF driver") Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 14:24:16 UTC |
1a6d281 | Yufeng Mo | 26 August 2021, 11:21:55 UTC | net: hns3: clear hardware resource when loading driver If a PF is bonded to a virtual machine and the virtual machine exits unexpectedly, some hardware resource cannot be cleared. In this case, loading driver may cause exceptions. Therefore, the hardware resource needs to be cleared when the driver is loaded. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 26 August 2021, 14:24:16 UTC |
ef52b4a | Kyle Tso | 26 August 2021, 12:42:01 UTC | usb: typec: tcpm: Raise vdm_sm_running flag only when VDM SM is running If the port is going to send Discover_Identity Message, vdm_sm_running flag was intentionally set before entering Ready States in order to avoid the conflict because the port and the port partner might start AMS at almost the same time after entering Ready States. However, the original design has a problem. When the port is doing DR_SWAP from Device to Host, it raises the flag. Later in the tcpm_send_discover_work, the flag blocks the procedure of sending the Discover_Identity and it might never be cleared until disconnection. Since there exists another flag send_discover representing that the port is going to send Discover_Identity or not, it is enough to use that flag to prevent the conflict. Also change the timing of the set/clear of vdm_sm_running to indicate whether the VDM SM is actually running or not. Fixes: c34e85fa69b9 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work") Cc: stable <stable@vger.kernel.org> Cc: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Kyle Tso <kyletso@google.com> Link: https://lore.kernel.org/r/20210826124201.1562502-1-kyletso@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 26 August 2021, 12:59:04 UTC |
c82cacd | Takashi Iwai | 26 August 2021, 12:41:27 UTC | usb: renesas-xhci: Prefer firmware loading on unknown ROM state The recent attempt to handle an unknown ROM state in the commit d143825baf15 ("usb: renesas-xhci: Fix handling of unknown ROM state") resulted in a regression and reverted later by the commit 44cf53602f5a ("Revert "usb: renesas-xhci: Fix handling of unknown ROM state""). The problem of the former fix was that it treated the failure of firmware loading as a fatal error. Since the firmware files aren't included in the standard linux-firmware tree, most users don't have them, hence they got the non-working system after that. The revert fixed the regression, but also it didn't make the firmware loading triggered even on the devices that do need it. So we need still a fix for them. This is another attempt to handle the unknown ROM state. Like the previous fix, this also tries to load the firmware when ROM shows unknown state. In this patch, however, the failure of a firmware loading (such as a missing firmware file) isn't handled as a fatal error any longer when ROM has been already detected, but it falls back to the ROM mode like before. The error is returned only when no ROM is detected and the firmware loading failed. Along with it, for simplifying the code flow, the detection and the check of ROM is factored out from renesas_fw_check_running() and done in the caller side, renesas_xhci_check_request_fw(). It avoids the redundant ROM checks. The patch was tested on Lenovo Thinkpad T14 gen (BIOS 1.34). Also it was confirmed that no regression is seen on another Thinkpad T14 machine that has worked without the patch, too. Fixes: 44cf53602f5a ("Revert "usb: renesas-xhci: Fix handling of unknown ROM state"") Cc: stable <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1189207 Link: https://lore.kernel.org/r/20210826124127.14789-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 26 August 2021, 12:56:59 UTC |
4a1e25c | Wesley Cheng | 25 August 2021, 04:28:55 UTC | usb: dwc3: gadget: Stop EP0 transfers during pullup disable During a USB cable disconnect, or soft disconnect scenario, a pending SETUP transaction may not be completed, leading to the following error: dwc3 a600000.dwc3: timed out waiting for SETUP phase If this occurs, then the entire pullup disable routine is skipped and proper cleanup and halting of the controller does not complete. Instead of returning an error (which is ignored from the UDC perspective), allow the pullup disable routine to continue, which will also handle disabling of EP0/1. This will end any active transfers as well. Ensure to clear any delayed_status also, as the timeout could happen within the STATUS stage. Fixes: bb0147364850 ("usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to do so") Cc: <stable@vger.kernel.org> Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/20210825042855.7977-1-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 26 August 2021, 11:48:58 UTC |
6c35ca0 | Arnd Bergmann | 23 August 2021, 21:41:27 UTC | Merge tag 'reset-fixes-for-v5.14' of git://git.pengutronix.de/pza/linux into arm/fixes Reset controller fixes for v5.14 Hide the Sparx5 reset driver unless the ARCH_SPARX5 or COMPILE_TEST options are enabled, to avoid unnecessarily asking users about this driver. Fix a return value argument type in the ZynqMP reset driver. * tag 'reset-fixes-for-v5.14' of git://git.pengutronix.de/pza/linux: reset: reset-zynqmp: Fixed the argument data type reset: RESET_MCHP_SPARX5 should depend on ARCH_SPARX5 Link: https://lore.kernel.org/r/e543959c5b5ee7b25686f81049bf187d602daeda.camel@pengutronix.de Signed-off-by: Arnd Bergmann <arnd@arndb.de> | 26 August 2021, 11:47:45 UTC |
51f1954 | Thinh Nguyen | 19 August 2021, 01:17:03 UTC | usb: dwc3: gadget: Fix dwc3_calc_trbs_left() We can't depend on the TRB's HWO bit to determine if the TRB ring is "full". A TRB is only available when the driver had processed it, not when the controller consumed and relinquished the TRB's ownership to the driver. Otherwise, the driver may overwrite unprocessed TRBs. This can happen when many transfer events accumulate and the system is slow to process them and/or when there are too many small requests. If a request is in the started_list, that means there is one or more unprocessed TRBs remained. Check this instead of the TRB's HWO bit whether the TRB ring is full. Fixes: c4233573f6ee ("usb: dwc3: gadget: prepare TRBs on update transfers too") Cc: <stable@vger.kernel.org> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/e91e975affb0d0d02770686afc3a5b9eb84409f6.1629335416.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 26 August 2021, 11:47:03 UTC |
71de496 | Swati Sharma | 12 August 2021, 13:11:07 UTC | drm/i915/dp: Drop redundant debug print drm_dp_dpcd_read/write already has debug error message. Drop redundant error messages which gives false status even if correct value is read in drm_dp_dpcd_read(). v2: -Added fixes tag (Ankit) v3: -Fixed build error (CI) Fixes: 9488a030ac91 ("drm/i915: Add support for enabling link status and recovery") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210812131107.5531-1-swati2.sharma@intel.com (cherry picked from commit b6dfa416172939edaa46a5a647457b94c6d94119) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> | 26 August 2021, 11:31:52 UTC |
a63bcf0 | Matthew Brost | 30 July 2021, 19:53:42 UTC | drm/i915: Fix syncmap memory leak A small race exists between intel_gt_retire_requests_timeout and intel_timeline_exit which could result in the syncmap not getting free'd. Rather than work to hard to seal this race, simply cleanup the syncmap on fini. unreferenced object 0xffff88813bc53b18 (size 96): comm "gem_close_race", pid 5410, jiffies 4294917818 (age 1105.600s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 ................ 00 00 00 00 00 00 00 00 6b 6b 6b 6b 06 00 00 00 ........kkkk.... backtrace: [<00000000120b863a>] __sync_alloc_leaf+0x1e/0x40 [i915] [<00000000042f6959>] __sync_set+0x1bb/0x240 [i915] [<0000000090f0e90f>] i915_request_await_dma_fence+0x1c7/0x400 [i915] [<0000000056a48219>] i915_request_await_object+0x222/0x360 [i915] [<00000000aaac4ee3>] i915_gem_do_execbuffer+0x1bd0/0x2250 [i915] [<000000003c9d830f>] i915_gem_execbuffer2_ioctl+0x405/0xce0 [i915] [<00000000fd7a8e68>] drm_ioctl_kernel+0xb0/0xf0 [drm] [<00000000e721ee87>] drm_ioctl+0x305/0x3c0 [drm] [<000000008b0d8986>] __x64_sys_ioctl+0x71/0xb0 [<0000000076c362a4>] do_syscall_64+0x33/0x80 [<00000000eb7a4831>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Fixes: 531958f6f357 ("drm/i915/gt: Track timeline activeness in enter/exit") Cc: <stable@vger.kernel.org> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210730195342.110234-1-matthew.brost@intel.com (cherry picked from commit faf890985e30d5e88cc3a7c50c1bcad32f89ab7c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> | 26 August 2021, 11:31:52 UTC |
733c99e | 王贇 | 26 August 2021, 03:42:42 UTC | net: fix NULL pointer reference in cipso_v4_doi_free In netlbl_cipsov4_add_std() when 'doi_def->map.std' alloc failed, we sometime observe panic: BUG: kernel NULL pointer dereference, address: ... RIP: 0010:cipso_v4_doi_free+0x3a/0x80 ... Call Trace: netlbl_cipsov4_add_std+0xf4/0x8c0 netlbl_cipsov4_add+0x13f/0x1b0 genl_family_rcv_msg_doit.isra.15+0x132/0x170 genl_rcv_msg+0x125/0x240 This is because in cipso_v4_doi_free() there is no check on 'doi_def->map.std' when 'doi_def->type' equal 1, which is possibe, since netlbl_cipsov4_add_std() haven't initialize it before alloc 'doi_def->map.std'. This patch just add the check to prevent panic happen for similar cases. Reported-by: Abaci <abaci@linux.alibaba.com> Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 11:20:47 UTC |
96a6b93 | Andrey Ignatov | 26 August 2021, 00:25:40 UTC | rtnetlink: Return correct error on changing device netns Currently when device is moved between network namespaces using RTM_NEWLINK message type and one of netns attributes (FLA_NET_NS_PID, IFLA_NET_NS_FD, IFLA_TARGET_NETNSID) but w/o specifying IFLA_IFNAME, and target namespace already has device with same name, userspace will get EINVAL what is confusing and makes debugging harder. Fix it so that userspace gets more appropriate EEXIST instead what makes debugging much easier. Before: # ./ifname.sh + ip netns add ns0 + ip netns exec ns0 ip link add l0 type dummy + ip netns exec ns0 ip link show l0 8: l0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 66:90:b5:d5:78:69 brd ff:ff:ff:ff:ff:ff + ip link add l0 type dummy + ip link show l0 10: l0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 6e:c6:1f:15:20:8d brd ff:ff:ff:ff:ff:ff + ip link set l0 netns ns0 RTNETLINK answers: Invalid argument After: # ./ifname.sh + ip netns add ns0 + ip netns exec ns0 ip link add l0 type dummy + ip netns exec ns0 ip link show l0 8: l0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 1e:4a:72:e3:e3:8f brd ff:ff:ff:ff:ff:ff + ip link add l0 type dummy + ip link show l0 10: l0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether f2:fc:fe:2b:7d:a6 brd ff:ff:ff:ff:ff:ff + ip link set l0 netns ns0 RTNETLINK answers: File exists The problem is that do_setlink() passes its `char *ifname` argument, that it gets from a caller, to __dev_change_net_namespace() as is (as `const char *pat`), but semantics of ifname and pat can be different. For example, __rtnl_newlink() does this: net/core/rtnetlink.c 3270 char ifname[IFNAMSIZ]; ... 3286 if (tb[IFLA_IFNAME]) 3287 nla_strscpy(ifname, tb[IFLA_IFNAME], IFNAMSIZ); 3288 else 3289 ifname[0] = '\0'; ... 3364 if (dev) { ... 3394 return do_setlink(skb, dev, ifm, extack, tb, ifname, status); 3395 } , i.e. do_setlink() gets ifname pointer that is always valid no matter if user specified IFLA_IFNAME or not and then do_setlink() passes this ifname pointer as is to __dev_change_net_namespace() as pat argument. But the pat (pattern) in __dev_change_net_namespace() is used as: net/core/dev.c 11198 err = -EEXIST; 11199 if (__dev_get_by_name(net, dev->name)) { 11200 /* We get here if we can't use the current device name */ 11201 if (!pat) 11202 goto out; 11203 err = dev_get_valid_name(net, dev, pat); 11204 if (err < 0) 11205 goto out; 11206 } As the result the `goto out` path on line 11202 is neven taken and instead of returning EEXIST defined on line 11198, __dev_change_net_namespace() returns an error from dev_get_valid_name() and this, in turn, will be EINVAL for ifname[0] = '\0' set earlier. Fixes: d8a5ec672768 ("[NET]: netlink support for moving devices between network namespaces.") Signed-off-by: Andrey Ignatov <rdna@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 11:08:08 UTC |
a423cbe | David S. Miller | 26 August 2021, 09:26:06 UTC | Merge branch 'dsa-hellcreek-fixes' Kurt Kanzenbach says: ==================== net: dsa: hellcreek: 802.1Qbv Fixes while using TAPRIO offloading on the Hirschmann hellcreek switch, I've noticed two issues in the current implementation: 1. The gate control list is incorrectly programmed 2. The admin base time is not set properly Fix it. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 09:26:06 UTC |
b7658ed | Kurt Kanzenbach | 25 August 2021, 13:58:13 UTC | net: dsa: hellcreek: Adjust schedule look ahead window Traffic schedules can only be started up to eight seconds within the future. Therefore, the driver periodically checks every two seconds whether the admin base time provided by the user is inside that window. If so the schedule is started. Otherwise the check is deferred. However, according to the programming manual the look ahead window size should be four - not eight - seconds. By using the proposed value of four seconds starting a schedule at a specified admin base time actually works as expected. Fixes: 24dfc6eb39b2 ("net: dsa: hellcreek: Add TAPRIO offloading support") Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 09:26:06 UTC |
a7db5ed | Kurt Kanzenbach | 25 August 2021, 13:58:12 UTC | net: dsa: hellcreek: Fix incorrect setting of GCL Currently the gate control list which is programmed into the hardware is incorrect resulting in wrong traffic schedules. The problem is the loop variables are incremented before they are referenced. Therefore, move the increment to the end of the loop. Fixes: 24dfc6eb39b2 ("net: dsa: hellcreek: Add TAPRIO offloading support") Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 09:26:05 UTC |
43fed4d | Rahul Lakkireddy | 25 August 2021, 21:29:42 UTC | cxgb4: dont touch blocked freelist bitmap after free When adapter init fails, the blocked freelist bitmap is already freed up and should not be touched. So, move the bitmap zeroing closer to where it was successfully allocated. Also handle adapter init failure unwind path immediately and avoid setting up RDMA memory windows. Fixes: 5b377d114f2b ("cxgb4: Add debugfs facility to inject FL starvation") Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 09:23:24 UTC |
38d5755 | David S. Miller | 26 August 2021, 09:20:34 UTC | Merge branch 'inet-siphash' Eric Dumazet says: ==================== inet: use siphash in exception handling A group of security researchers brought to our attention the weakness of hash functions used in rt6_exception_hash() and fnhe_hashfun() I made two distinct patches to help backports, since IPv6 part was added in 4.15 ==================== Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 09:20:34 UTC |
6457378 | Eric Dumazet | 25 August 2021, 23:17:29 UTC | ipv4: use siphash instead of Jenkins in fnhe_hashfun() A group of security researchers brought to our attention the weakness of hash function used in fnhe_hashfun(). Lets use siphash instead of Jenkins Hash, to considerably reduce security risks. Also remove the inline keyword, this really is distracting. Fixes: d546c621542d ("ipv4: harden fnhe_hashfun()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Keyu Man <kman001@ucr.edu> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 09:20:34 UTC |
4785305 | Eric Dumazet | 25 August 2021, 23:17:28 UTC | ipv6: use siphash in rt6_exception_hash() A group of security researchers brought to our attention the weakness of hash function used in rt6_exception_hash() Lets use siphash instead of Jenkins Hash, to considerably reduce security risks. Following patch deals with IPv4. Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Keyu Man <kman001@ucr.edu> Cc: Wei Wang <weiwan@google.com> Cc: Martin KaFai Lau <kafai@fb.com> Acked-by: Wei Wang <weiwan@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 09:20:34 UTC |
92ea47f | David S. Miller | 26 August 2021, 08:37:40 UTC | Merge tag 'linux-can-fixes-for-5.14-20210826' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine says: ==================== pull-request: can 2021-08-26 this is a pull request of a single patch for net/master. Stefan Mätje's patch fixes the interchange of RX and TX error counters inthe esd_usb2 CAN driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> | 26 August 2021, 08:37:40 UTC |
662b932 | Greg Kroah-Hartman | 26 August 2021, 08:27:18 UTC | Merge tag 'usb-serial-5.14-rc8' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.14-rc8 Here's a fix for a regression in 5.14 (also backported to stable) which caused reads to stall for ch341 devices. Included is also a new modem device id. All but the revert have been in linux-next, and with no reported issues. * tag 'usb-serial-5.14-rc8' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: Revert "USB: serial: ch341: fix character loss at high transfer rates" USB: serial: option: add new VID/PID to support Fibocom FG150 | 26 August 2021, 08:27:18 UTC |
ccf2648 | Kim Phillips | 17 August 2021, 22:10:43 UTC | perf/x86/amd/power: Assign pmu.module Assign pmu.module so the driver can't be unloaded whilst in use. Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20210817221048.88063-4-kim.phillips@amd.com | 26 August 2021, 07:12:57 UTC |
f11dd0d | Kim Phillips | 17 August 2021, 22:10:41 UTC | perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op Commit: 2ff40250691e ("perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs") neglected to do so. Fixes: 2ff40250691e ("perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs") Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210817221048.88063-2-kim.phillips@amd.com | 26 August 2021, 06:58:02 UTC |
26db2e0 | Kim Phillips | 17 August 2021, 22:10:42 UTC | perf/x86/amd/ibs: Work around erratum #1197 Erratum #1197 "IBS (Instruction Based Sampling) Register State May be Incorrect After Restore From CC6" is published in a document: "Revision Guide for AMD Family 19h Models 00h-0Fh Processors" 56683 Rev. 1.04 July 2021 https://bugzilla.kernel.org/show_bug.cgi?id=206537 Implement the erratum's suggested workaround and ignore IBS samples if MSRC001_1031 == 0. Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20210817221048.88063-3-kim.phillips@amd.com | 26 August 2021, 06:58:02 UTC |
0b3a873 | Colin Ian King | 06 July 2021, 11:45:53 UTC | perf/x86/intel/uncore: Fix integer overflow on 23 bit left shift of a u32 The u32 variable pci_dword is being masked with 0x1fffffff and then left shifted 23 places. The shift is a u32 operation,so a value of 0x200 or more in pci_dword will overflow the u32 and only the bottow 32 bits are assigned to addr. I don't believe this was the original intent. Fix this by casting pci_dword to a resource_size_t to ensure no overflow occurs. Note that the mask and 12 bit left shift operation does not need this because the mask SNR_IMC_MMIO_MEM0_MASK and shift is always a 32 bit value. Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge") Addresses-Coverity: ("Unintentional integer overflow") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lore.kernel.org/r/20210706114553.28249-1-colin.king@canonical.com | 26 August 2021, 06:58:02 UTC |
044012b | Stefan Mätje | 25 August 2021, 21:52:27 UTC | can: usb: esd_usb2: esd_usb2_rx_event(): fix the interchange of the CAN RX and TX error counters This patch fixes the interchanged fetch of the CAN RX and TX error counters from the ESD_EV_CAN_ERROR_EXT message. The RX error counter is really in struct rx_msg::data[2] and the TX error counter is in struct rx_msg::data[3]. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Link: https://lore.kernel.org/r/20210825215227.4947-2-stefan.maetje@esd.eu Cc: stable@vger.kernel.org Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> | 26 August 2021, 06:37:13 UTC |
ec92e52 | kernel test robot | 25 August 2021, 18:35:38 UTC | net: usb: asix: ax88772: fix boolconv.cocci warnings drivers/net/usb/asix_devices.c:757:60-65: WARNING: conversion to bool not needed here Remove unneeded conversion to bool Semantic patch information: Relational and logical operators evaluate to bool, explicit conversion is overly verbose and unneeded. Generated by: scripts/coccinelle/misc/boolconv.cocci Fixes: 7a141e64cf14 ("net: usb: asix: ax88772: move embedded PHY detection as early as possible") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20210825183538.13070-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 25 August 2021, 23:35:51 UTC |
062b829 | Trond Myklebust | 25 August 2021, 19:33:14 UTC | SUNRPC: Fix XPT_BUSY flag leakage in svc_handle_xprt()... If the attempt to reserve a slot fails, we currently leak the XPT_BUSY flag on the socket. Among other things, this make it impossible to close the socket. Fixes: 82011c80b3ec ("SUNRPC: Move svc_xprt_received() call sites") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> | 25 August 2021, 20:58:09 UTC |
73f3af7 | Linus Torvalds | 25 August 2021, 19:45:31 UTC | Merge branch 'akpm' (patches from Andrew) Merge fixes from Andrew Morton: "2 patches. Subsystems affected by this patch series: mm/memory-hotplug and MAINTAINERS" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: MAINTAINERS: exfat: update my email address mm/memory_hotplug: fix potential permanent lru cache disable | 25 August 2021, 19:45:31 UTC |
a34cc13 | Namjae Jeon | 25 August 2021, 19:17:58 UTC | MAINTAINERS: exfat: update my email address My email address in exfat entry will be not available in a few days. Update it to my own kernel.org address. Link: https://lkml.kernel.org/r/20210825044833.16806-1-namjae.jeon@samsung.com Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 25 August 2021, 19:25:12 UTC |
946746d | Miaohe Lin | 25 August 2021, 19:17:55 UTC | mm/memory_hotplug: fix potential permanent lru cache disable If offline_pages failed after lru_cache_disable(), it forgot to do lru_cache_enable() in error path. So we would have lru cache disabled permanently in this case. Link: https://lkml.kernel.org/r/20210821094246.10149-3-linmiaohe@huawei.com Fixes: d479960e44f2 ("mm: disable LRU pagevec during the migration temporarily") Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Oscar Salvador <osalvador@suse.de> Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com> Cc: Chris Goldsworthy <cgoldswo@codeaurora.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Minchan Kim <minchan@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 25 August 2021, 19:25:12 UTC |
3c5a272 | Dmitry Osipenko | 23 August 2021, 20:24:12 UTC | PM: domains: Improve runtime PM performance state handling GENPD core doesn't support handling performance state changes while consumer device is runtime-suspended or when runtime PM is disabled. GENPD core may override performance state that was configured by device driver while RPM of the device was disabled or device was RPM-suspended. Let's close that gap by allowing drivers to control performance state while RPM of a consumer device is disabled and to set up performance state of RPM-suspended device that will be applied by GENPD core on RPM-resume of the device. Fixes: 5937c3ce2122 ("PM: domains: Drop/restore performance state votes for devices at runtime PM") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 25 August 2021, 18:15:54 UTC |
fe67f4d | Linus Torvalds | 24 August 2021, 17:39:25 UTC | pipe: do FASYNC notifications for every pipe IO, not just state changes It turns out that the SIGIO/FASYNC situation is almost exactly the same as the EPOLLET case was: user space really wants to be notified after every operation. Now, in a perfect world it should be sufficient to only notify user space on "state transitions" when the IO state changes (ie when a pipe goes from unreadable to readable, or from unwritable to writable). User space should then do as much as possible - fully emptying the buffer or what not - and we'll notify it again the next time the state changes. But as with EPOLLET, we have at least one case (stress-ng) where the kernel sent SIGIO due to the pipe being marked for asynchronous notification, but the user space signal handler then didn't actually necessarily read it all before returning (it read more than what was written, but since there could be multiple writes, it could leave data pending). The user space code then expected to get another SIGIO for subsequent writes - even though the pipe had been readable the whole time - and would only then read more. This is arguably a user space bug - and Colin King already fixed the stress-ng code in question - but the kernel regression rules are clear: it doesn't matter if kernel people think that user space did something silly and wrong. What matters is that it used to work. So if user space depends on specific historical kernel behavior, it's a regression when that behavior changes. It's on us: we were silly to have that non-optimal historical behavior, and our old kernel behavior was what user space was tested against. Because of how the FASYNC notification was tied to wakeup behavior, this was first broken by commits f467a6a66419 and 1b6b26ae7053 ("pipe: fix and clarify pipe read/write wakeup logic"), but at the time it seems nobody noticed. Probably because the stress-ng problem case ends up being timing-dependent too. It was then unwittingly fixed by commit 3a34b13a88ca ("pipe: make pipe writes always wake up readers") only to be broken again when by commit 3b844826b6c6 ("pipe: avoid unnecessary EPOLLET wakeups under normal loads"). And at that point the kernel test robot noticed the performance refression in the stress-ng.sigio.ops_per_sec case. So the "Fixes" tag below is somewhat ad hoc, but it matches when the issue was noticed. Fix it for good (knock wood) by simply making the kill_fasync() case separate from the wakeup case. FASYNC is quite rare, and we clearly shouldn't even try to use the "avoid unnecessary wakeups" logic for it. Link: https://lore.kernel.org/lkml/20210824151337.GC27667@xsang-OptiPlex-9020/ Fixes: 3b844826b6c6 ("pipe: avoid unnecessary EPOLLET wakeups under normal loads") Reported-by: kernel test robot <oliver.sang@intel.com> Tested-by: Oliver Sang <oliver.sang@intel.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Colin Ian King <colin.king@canonical.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 25 August 2021, 17:27:16 UTC |
62add98 | Linus Torvalds | 25 August 2021, 16:56:10 UTC | Merge branch 'for-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace Pull ucount fixes from Eric Biederman: "This branch fixes a regression that made it impossible to increase rlimits that had been converted to the ucount infrastructure, and also fixes a reference counting bug where the reference was not incremented soon enough. The fixes are trivial and the bugs have been encountered in the wild, and the fixes have been tested" * 'for-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: ucounts: Increase ucounts reference counter before the security hook ucounts: Fix regression preventing increasing of rlimits in init_user_ns | 25 August 2021, 16:56:10 UTC |
a9e6ffb | Tuo Li | 05 August 2021, 15:14:34 UTC | ceph: fix possible null-pointer dereference in ceph_mdsmap_decode() kcalloc() is called to allocate memory for m->m_info, and if it fails, ceph_mdsmap_destroy() behind the label out_err will be called: ceph_mdsmap_destroy(m); In ceph_mdsmap_destroy(), m->m_info is dereferenced through: kfree(m->m_info[i].export_targets); To fix this possible null-pointer dereference, check m->m_info before the for loop to free m->m_info[i].export_targets. [ jlayton: fix up whitespace damage only kfree(m->m_info) if it's non-NULL ] Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Tuo Li <islituo@gmail.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> | 25 August 2021, 14:34:11 UTC |
b2f9fa1 | Xiubo Li | 18 August 2021, 13:38:42 UTC | ceph: correctly handle releasing an embedded cap flush The ceph_cap_flush structures are usually dynamically allocated, but the ceph_cap_snap has an embedded one. When force umounting, the client will try to remove all the session caps. During this, it will free them, but that should not be done with the ones embedded in a capsnap. Fix this by adding a new boolean that indicates that the cap flush is embedded in a capsnap, and skip freeing it if that's set. At the same time, switch to using list_del_init() when detaching the i_list and g_list heads. It's possible for a forced umount to remove these objects but then handle_cap_flushsnap_ack() races in and does the list_del_init() again, corrupting memory. Cc: stable@vger.kernel.org URL: https://tracker.ceph.com/issues/52283 Signed-off-by: Xiubo Li <xiubli@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> | 25 August 2021, 14:34:11 UTC |
c53c6b7 | Xiaoyao Li | 24 August 2021, 04:06:22 UTC | perf/x86/intel/pt: Fix mask of num_address_ranges Per SDM, bit 2:0 of CPUID(0x14,1).EAX[2:0] reports the number of configurable address ranges for filtering, not bit 1:0. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Link: https://lkml.kernel.org/r/20210824040622.4081502-1-xiaoyao.li@intel.com | 25 August 2021, 13:42:31 UTC |
4e96557 | Qu Wenruo | 25 August 2021, 05:41:42 UTC | Revert "btrfs: compression: don't try to compress if we don't have enough pages" This reverts commit f2165627319ffd33a6217275e5690b1ab5c45763. [BUG] It's no longer possible to create compressed inline extent after commit f2165627319f ("btrfs: compression: don't try to compress if we don't have enough pages"). [CAUSE] For compression code, there are several possible reasons we have a range that needs to be compressed while it's no more than one page. - Compressed inline write The data is always smaller than one sector and the test lacks the condition to properly recognize a non-inline extent. - Compressed subpage write For the incoming subpage compressed write support, we require page alignment of the delalloc range. And for 64K page size, we can compress just one page into smaller sectors. For those reasons, the requirement for the data to be more than one page is not correct, and is already causing regression for compressed inline data writeback. The idea of skipping one page to avoid wasting CPU time could be revisited in the future. [FIX] Fix it by reverting the offending commit. Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org> Link: https://lore.kernel.org/linux-btrfs/afa2742.c084f5d6.17b6b08dffc@tnonline.net Fixes: f2165627319f ("btrfs: compression: don't try to compress if we don't have enough pages") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> | 25 August 2021, 13:08:19 UTC |
3eb9cdf | Will Deacon | 25 August 2021, 10:10:07 UTC | Partially revert "arm64/mm: drop HAVE_ARCH_PFN_VALID" This partially reverts commit 16c9afc776608324ca71c0bc354987bab532f51d. Alex Bee reports a regression in 5.14 on their RK3328 SoC when configuring the PL330 DMA controller: | ------------[ cut here ]------------ | WARNING: CPU: 2 PID: 373 at kernel/dma/mapping.c:235 dma_map_resource+0x68/0xc0 | Modules linked in: spi_rockchip(+) fuse | CPU: 2 PID: 373 Comm: systemd-udevd Not tainted 5.14.0-rc7 #1 | Hardware name: Pine64 Rock64 (DT) | pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) | pc : dma_map_resource+0x68/0xc0 | lr : pl330_prep_slave_fifo+0x78/0xd0 This appears to be because dma_map_resource() is being called for a physical address which does not correspond to a memory address yet does have a valid 'struct page' due to the way in which the vmemmap is constructed. Prior to 16c9afc77660 ("arm64/mm: drop HAVE_ARCH_PFN_VALID"), the arm64 implementation of pfn_valid() called memblock_is_memory() to return 'false' for such regions and the DMA mapping request would proceed. However, now that we are using the generic implementation where only the presence of the memory map entry is considered, we return 'true' and erroneously fail with DMA_MAPPING_ERROR because we identify the region as DRAM. Although fixing this in the DMA mapping code is arguably the right fix, it is a risky, cross-architecture change at this stage in the cycle. So just revert arm64 back to its old pfn_valid() implementation for v5.14. The change to the generic pfn_valid() code is preserved from the original patch, so as to avoid impacting other architectures. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Christoph Hellwig <hch@lst.de> Reported-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/d3a3c828-b777-faf8-e901-904995688437@gmail.com Signed-off-by: Will Deacon <will@kernel.org> | 25 August 2021, 10:33:24 UTC |
cd9b50a | Davide Caratti | 24 August 2021, 22:33:48 UTC | net/sched: ets: fix crash when flipping from 'strict' to 'quantum' While running kselftests, Hangbin observed that sch_ets.sh often crashes, and splats like the following one are seen in the output of 'dmesg': BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 159f12067 P4D 159f12067 PUD 159f13067 PMD 0 Oops: 0000 [#1] SMP NOPTI CPU: 2 PID: 921 Comm: tc Not tainted 5.14.0-rc6+ #458 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 RIP: 0010:__list_del_entry_valid+0x2d/0x50 Code: 48 8b 57 08 48 b9 00 01 00 00 00 00 ad de 48 39 c8 0f 84 ac 6e 5b 00 48 b9 22 01 00 00 00 00 ad de 48 39 ca 0f 84 cf 6e 5b 00 <48> 8b 32 48 39 fe 0f 85 af 6e 5b 00 48 8b 50 08 48 39 f2 0f 85 94 RSP: 0018:ffffb2da005c3890 EFLAGS: 00010217 RAX: 0000000000000000 RBX: ffff9073ba23f800 RCX: dead000000000122 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff9073ba23fbc8 RBP: ffff9073ba23f890 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: dead000000000100 R13: ffff9073ba23fb00 R14: 0000000000000002 R15: 0000000000000002 FS: 00007f93e5564e40(0000) GS:ffff9073bba00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000014ad34000 CR4: 0000000000350ee0 Call Trace: ets_qdisc_reset+0x6e/0x100 [sch_ets] qdisc_reset+0x49/0x1d0 tbf_reset+0x15/0x60 [sch_tbf] qdisc_reset+0x49/0x1d0 dev_reset_queue.constprop.42+0x2f/0x90 dev_deactivate_many+0x1d3/0x3d0 dev_deactivate+0x56/0x90 qdisc_graft+0x47e/0x5a0 tc_get_qdisc+0x1db/0x3e0 rtnetlink_rcv_msg+0x164/0x4c0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x242/0x480 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1f2/0x260 ___sys_sendmsg+0x7c/0xc0 __sys_sendmsg+0x57/0xa0 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f93e44b8338 Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 RSP: 002b:00007ffc0db737a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000061255c06 RCX: 00007f93e44b8338 RDX: 0000000000000000 RSI: 00007ffc0db73810 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 000000000000000b R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000687880 R14: 0000000000000000 R15: 0000000000000000 Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev i2c_i801 pcspkr i2c_smbus lpc_ich virtio_balloon ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel libata serio_raw virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod CR2: 0000000000000000 When the change() function decreases the value of 'nstrict', we must take into account that packets might be already enqueued on a class that flips from 'strict' to 'quantum': otherwise that class will not be added to the bandwidth-sharing list. Then, a call to ets_qdisc_reset() will attempt to do list_del(&alist) with 'alist' filled with zero, hence the NULL pointer dereference. For classes flipping from 'strict' to 'quantum', initialize an empty list and eventually add it to the bandwidth-sharing list, if there are packets already enqueued. In this way, the kernel will: a) prevent crashing as described above. b) avoid retaining the backlog packets (for an arbitrarily long time) in case no packet is enqueued after a change from 'strict' to 'quantum'. Reported-by: Hangbin Liu <liuhangbin@gmail.com> Fixes: dcc68b4d8084 ("net: sch_ets: Add a new Qdisc") Signed-off-by: Davide Caratti <dcaratti@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 25 August 2021, 10:15:30 UTC |
e543468 | Shai Malin | 24 August 2021, 16:52:49 UTC | qede: Fix memset corruption Thanks to Kees Cook who detected the problem of memset that starting from not the first member, but sized for the whole struct. The better change will be to remove the redundant memset and to clear only the msix_cnt member. Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com> Signed-off-by: Ariel Elior <aelior@marvell.com> Signed-off-by: Shai Malin <smalin@marvell.com> Reported-by: Kees Cook <keescook@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net> | 25 August 2021, 10:07:55 UTC |
2b9fff6 | Song Yoong Siang | 25 August 2021, 00:57:42 UTC | net: stmmac: fix kernel panic due to NULL pointer dereference of buf->xdp Ensure a valid XSK buffer before proceed to free the xdp buffer. The following kernel panic is observed without this patch: RIP: 0010:xp_free+0x5/0x40 Call Trace: stmmac_napi_poll_rxtx+0x332/0xb30 [stmmac] ? stmmac_tx_timer+0x3c/0xb0 [stmmac] net_rx_action+0x13d/0x3d0 __do_softirq+0xfc/0x2fb ? smpboot_register_percpu_thread+0xe0/0xe0 run_ksoftirqd+0x32/0x70 smpboot_thread_fn+0x1d8/0x2c0 kthread+0x169/0x1a0 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 ---[ end trace 0000000000000002 ]--- Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy") Cc: <stable@vger.kernel.org> # 5.13.x Suggested-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 25 August 2021, 09:59:39 UTC |
a645119 | Song Yoong Siang | 25 August 2021, 00:55:29 UTC | net: stmmac: fix kernel panic due to NULL pointer dereference of xsk_pool After free xsk_pool, there is possibility that napi polling is still running in the middle, thus causes a kernel crash due to kernel NULL pointer dereference of rx_q->xsk_pool and tx_q->xsk_pool. Fix this by changing the XDP pool setup sequence to: 1. disable napi before free xsk_pool 2. enable napi after init xsk_pool The following kernel panic is observed without this patch: RIP: 0010:xsk_uses_need_wakeup+0x5/0x10 Call Trace: stmmac_napi_poll_rxtx+0x3a9/0xae0 [stmmac] __napi_poll+0x27/0x130 net_rx_action+0x233/0x280 __do_softirq+0xe2/0x2b6 run_ksoftirqd+0x1a/0x20 smpboot_thread_fn+0xac/0x140 ? sort_range+0x20/0x20 kthread+0x124/0x150 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 ---[ end trace a77c8956b79ac107 ]--- Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy") Cc: <stable@vger.kernel.org> # 5.13.x Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 25 August 2021, 09:59:39 UTC |
8552007 | Harini Katakam | 24 August 2021, 10:02:09 UTC | net: macb: Add a NULL check on desc_ptp macb_ptp_desc will not return NULL under most circumstances with correct Kconfig and IP design config register. But for the sake of the extreme corner case, check for NULL when using the helper. In case of rx_tstamp, no action is necessary except to return (similar to timestamp disabled) and warn. In case of TX, return -EINVAL to let the skb be free. Perform this check before marking skb in progress. Fixes coverity warning: (4) Event dereference: Dereferencing a null pointer "desc_ptp" Signed-off-by: Harini Katakam <harini.katakam@xilinx.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 25 August 2021, 09:39:17 UTC |
2d26f6e | Michael Riesch | 23 August 2021, 14:37:54 UTC | net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings This reverts commit 2c896fb02e7f65299646f295a007bda043e0f382 "net: stmmac: dwmac-rk: add pd_gmac support for rk3399" and fixes unbalanced pm_runtime_enable warnings. In the commit to be reverted, support for power management was introduced to the Rockchip glue code. Later, power management support was introduced to the stmmac core code, resulting in multiple invocations of pm_runtime_{enable,disable,get_sync,put_sync}. The multiple invocations happen in rk_gmac_powerup and stmmac_{dvr_probe, resume} as well as in rk_gmac_powerdown and stmmac_{dvr_remove, suspend}, respectively, which are always called in conjunction. Fixes: 5ec55823438e850c91c6b92aec93fb04ebde29e2 ("net: stmmac: add clocks management for gmac driver") Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: David S. Miller <davem@davemloft.net> | 25 August 2021, 09:37:17 UTC |
df7b16d | Johan Hovold | 24 August 2021, 12:19:26 UTC | Revert "USB: serial: ch341: fix character loss at high transfer rates" This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b. These devices do not appear to send a zero-length packet when the transfer size is a multiple of the bulk-endpoint max-packet size. This means that incoming data may not be processed by the driver until a short packet is received or the receive buffer is full. Revert back to using endpoint-sized receive buffers to avoid stalled reads. Reported-by: Paul Größel <pb.g@gmx.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131 Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates") Cc: stable@vger.kernel.org Cc: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20210824121926.19311-1-johan@kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> | 25 August 2021, 07:13:33 UTC |