- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 60f1bf29c0b2519989927cae640cd1f50f59dc7f Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Fri, 11 Jan 2019 15:18:22 +0100 Subject: [PATCH] s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU When calling smp_call_ipl_cpu() from the IPL CPU, we will try to read from pcpu_devices->lowcore. However, due to prefixing, that will result in reading from absolute address 0 on that CPU. We have to go via the actual lowcore instead. This means that right now, we will read lc->nodat_stack == 0 and therfore work on a very wrong stack. This BUG essentially broke rebooting under QEMU TCG (which will report a low address protection exception). And checking under KVM, it is also broken under KVM. With 1 VCPU it can be easily triggered. :/# echo 1 > /proc/sys/kernel/sysrq :/# echo b > /proc/sysrq-trigger [ 28.476745] sysrq: SysRq : Resetting [ 28.476793] Kernel stack overflow. [ 28.476817] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13 [ 28.476820] Hardware name: IBM 2964 NE1 716 (KVM/Linux) [ 28.476826] Krnl PSW : 0400c00180000000 0000000000115c0c (pcpu_delegate+0x12c/0x140) [ 28.476861] R:0 T:1 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 [ 28.476863] Krnl GPRS: ffffffffffffffff 0000000000000000 000000000010dff8 0000000000000000 [ 28.476864] 0000000000000000 0000000000000000 0000000000ab7090 000003e0006efbf0 [ 28.476864] 000000000010dff8 0000000000000000 0000000000000000 0000000000000000 [ 28.476865] 000000007fffc000 0000000000730408 000003e0006efc58 0000000000000000 [ 28.476887] Krnl Code: 0000000000115bfe: 4170f000 la %r7,0(%r15) [ 28.476887] 0000000000115c02: 41f0a000 la %r15,0(%r10) [ 28.476887] #0000000000115c06: e370f0980024 stg %r7,152(%r15) [ 28.476887] >0000000000115c0c: c0e5fffff86e brasl %r14,114ce8 [ 28.476887] 0000000000115c12: 41f07000 la %r15,0(%r7) [ 28.476887] 0000000000115c16: a7f4ffa8 brc 15,115b66 [ 28.476887] 0000000000115c1a: 0707 bcr 0,%r7 [ 28.476887] 0000000000115c1c: 0707 bcr 0,%r7 [ 28.476901] Call Trace: [ 28.476902] Last Breaking-Event-Address: [ 28.476920] [<0000000000a01c4a>] arch_call_rest_init+0x22/0x80 [ 28.476927] Kernel panic - not syncing: Corrupt kernel stack, can't continue. [ 28.476930] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13 [ 28.476932] Hardware name: IBM 2964 NE1 716 (KVM/Linux) [ 28.476932] Call Trace: Fixes: 2f859d0dad81 ("s390/smp: reduce size of struct pcpu") Cc: stable(a)vger.kernel.org # 4.0+ Reported-by: Cornelia Huck <cohuck(a)redhat.com> Signed-off-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c index 307a1c86ea21..b198ece2aad6 100644 --- a/arch/s390/kernel/smp.c +++ b/arch/s390/kernel/smp.c @@ -381,8 +381,13 @@ void smp_call_online_cpu(void (*func)(void *), void *data) */ void smp_call_ipl_cpu(void (*func)(void *), void *data) { + struct lowcore *lc = pcpu_devices->lowcore; + + if (pcpu_devices[0].address == stap()) + lc = &S390_lowcore; + pcpu_delegate(&pcpu_devices[0], func, data, - pcpu_devices->lowcore->nodat_stack); + lc->nodat_stack); } int smp_find_processor_id(u16 address)

6 years, 8 months

3
2
0 0

[PATCH] irqchip/gic-v3-its: Align PCI Multi-MSI allocation on their size

by Ard Biesheuvel

From: Marc Zyngier <marc.zyngier(a)arm.com> Commit 8208d1708b88b412ca97f50a6d951242c88cbbac upstream. The way we allocate events works fine in most cases, except when multiple PCI devices share an ITS-visible DevID, and that one of them is trying to use MultiMSI allocation. In that case, our allocation is not guaranteed to be zero-based anymore, and we have to make sure we allocate it on a boundary that is compatible with the PCI Multi-MSI constraints. Fix this by allocating the full region upfront instead of iterating over the number of MSIs. MSI-X are always allocated one by one, so this shouldn't change anything on that front. Fixes: b48ac83d6bbc2 ("irqchip: GICv3: ITS: MSI support") Cc: <stable(a)vger.kernel.org> # v4.4 - v4.9 Reported-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> [ardb: rebased onto v4.9.153, should apply cleanly onto v4.4.y as well] Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- drivers/irqchip/irq-gic-v3-its.c | 25 ++++++++++---------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 558c7589c329..83ca754250fb 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1372,13 +1372,14 @@ static void its_free_device(struct its_device *its_dev) kfree(its_dev); } -static int its_alloc_device_irq(struct its_device *dev, irq_hw_number_t *hwirq) +static int its_alloc_device_irq(struct its_device *dev, int nvecs, irq_hw_number_t *hwirq) { int idx; - idx = find_first_zero_bit(dev->event_map.lpi_map, - dev->event_map.nr_lpis); - if (idx == dev->event_map.nr_lpis) + idx = bitmap_find_free_region(dev->event_map.lpi_map, + dev->event_map.nr_lpis, + get_count_order(nvecs)); + if (idx < 0) return -ENOSPC; *hwirq = dev->event_map.lpi_base + idx; @@ -1464,20 +1465,20 @@ static int its_irq_domain_alloc(struct irq_domain *domain, unsigned int virq, int err; int i; - for (i = 0; i < nr_irqs; i++) { - err = its_alloc_device_irq(its_dev, &hwirq); - if (err) - return err; + err = its_alloc_device_irq(its_dev, nr_irqs, &hwirq); + if (err) + return err; - err = its_irq_gic_domain_alloc(domain, virq + i, hwirq); + for (i = 0; i < nr_irqs; i++) { + err = its_irq_gic_domain_alloc(domain, virq + i, hwirq + i); if (err) return err; irq_domain_set_hwirq_and_chip(domain, virq + i, - hwirq, &its_irq_chip, its_dev); + hwirq + i, &its_irq_chip, its_dev); pr_debug("ID:%d pID:%d vID:%d\n", - (int)(hwirq - its_dev->event_map.lpi_base), - (int) hwirq, virq + i); + (int)(hwirq + i - its_dev->event_map.lpi_base), + (int)(hwirq + i), virq + i); } return 0; -- 2.20.1

6 years, 8 months

2
1
0 0

Re: Request for stable backport: stmmac: Use correct values in TQS/RQS fields

by Niklas Cassel

Adding stable since I see Greg's Sign-off-by on recent backports to this driver. On Wed, Dec 19, 2018 at 10:55:16AM +0100, Niklas Cassel wrote: > Hello David, > > I can observe a netdev watchdog timeout on kernel 4.14.78 when using stmmac > with multiple tx queues. > > Backporting the following commit: > > commit 52a76235d0c4dd259cd0df503afed4757c04ba1d > Author: Jose Abreu <Jose.Abreu(a)synopsys.com> > Date: Fri Oct 13 10:58:36 2017 +0100 > > net: stmmac: Use correct values in TQS/RQS fields > > Currently we are using all the available fifo size in RQS and > TQS fields. This will not work correctly in multi-queues IP's > because total fifo size must be splitted to the enabled queues. > > Correct this by computing the available fifo size per queue and > setting the right value in TQS and RQS fields. > > Signed-off-by: Jose Abreu <joabreu(a)synopsys.com> > Cc: David S. Miller <davem(a)davemloft.net> > Cc: Joao Pinto <jpinto(a)synopsys.com> > Cc: Giuseppe Cavallaro <peppe.cavallaro(a)st.com> > Cc: Alexandre Torgue <alexandre.torgue(a)st.com> > Signed-off-by: David S. Miller <davem(a)davemloft.net> > > > resolves the issue. > > The fix was first included in v4.15 > $ git tag --contains 52a76235d0c4dd259cd0df503afed4757c04ba1d > v4.15 > v4.15-rc1 > v4.15-rc2 > > Could you please queue it up for 4.14 stable? > > > Kind regards, > Niklas

6 years, 8 months

2
1
0 0

Re: [PATCH v2] HID: debug: fix the ring buffer implementation

by Vladis Dronov

Hi, > The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96, > v4.9.153, v4.4.172, v3.18.133. > > v4.20.5: Build OK! > v4.19.18: Build OK! > v4.14.96: Failed to apply! Possible dependencies: > v4.9.153: Failed to apply! Possible dependencies: > v4.4.172: Failed to apply! Possible dependencies: > v3.18.133: Failed to apply! Possible dependencies: > > How should we proceed with this patch? Unfortunately, I have no idea how stable trees process failed-to-apply patches. The obvious answer would be "backport it". Best regards, Vladis Dronov | Red Hat, Inc. | Product Security | Senior Software Engineer

6 years, 8 months

1
0
0 0

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 9f1a389a0b5b Linux 4.20.5 The results of these automated tests are provided below. Overall result: FAILED (see details below) Patch merge: OK Compile: OK Kernel tests: FAILED One or more kernel tests failed: powerpc64le: PASSED s390x: PASSED aarch64: PASSED x86_64: PASSED We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 9f1a389a0b5b Linux 4.20.5 We then merged the following patches with `git am`: amd-xgbe-fix-mdio-access-for-non-zero-ports-and-clause-45-phys.patch net-bridge-fix-ethernet-header-pointer-before-check-skb-forwardable.patch net-fix-usage-of-pskb_trim_rcsum.patch net-phy-marvell-errata-for-mv88e6390-internal-phys.patch net-phy-mdio_bus-add-missing-device_del-in-mdiobus_register-error-handling.patch net-phy-phy-driver-features-are-mandatory.patch net-sched-act_tunnel_key-fix-memory-leak-in-case-of-action-replace.patch net_sched-refetch-skb-protocol-for-each-filter.patch openvswitch-avoid-oob-read-when-parsing-flow-nlattrs.patch vhost-log-dirty-page-correctly.patch mlxsw-pci-increase-pci-sw-reset-timeout.patch net-ipv4-fix-memory-leak-in-network-namespace-dismantle.patch mlxsw-spectrum_fid-update-dummy-fid-index.patch mlxsw-pci-ring-cq-s-doorbell-before-rdq-s.patch net-sched-cls_flower-allocate-mask-dynamically-in-fl_change.patch udp-with-udp_segment-release-on-error-path.patch ip6_gre-fix-tunnel-list-corruption-for-x-netns.patch erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch net-phy-marvell-fix-deadlock-from-wrong-locking.patch ip6_gre-update-version-related-info-when-changing-link.patch tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch arm-fix-the-cockup-in-the-previous-patch.patch sunrpc-address-kerberos-performance-behavior-regress.patch mei-me-mark-lbg-devices-as-having-dma-support.patch mei-me-add-denverton-innovation-engine-device-ids.patch usb-leds-fix-regression-in-usbport-led-trigger.patch usb-ehci-ehci-mv-add-module_device_table.patch usb-serial-ftdi_sio-fix-gpio-not-working-in-autosuspend.patch usb-serial-simple-add-motorola-tetra-tpg2200-device-id.patch usb-serial-pl2303-add-new-pid-to-support-pl2303tb.patch ceph-clear-inode-pointer-when-snap-realm-gets-dropped-by-its-inode.patch asoc-atom-fix-a-missing-check-of-snd_pcm_lib_malloc_pages.patch asoc-rt5514-spi-fix-potential-null-pointer-dereference.patch asoc-tlv320aic32x4-kernel-oops-while-entering-dapm-standby-mode.patch clk-zynqmp-fix-memory-allocation-in-zynqmp_clk_setup.patch clk-socfpga-stratix10-fix-rate-calculation-for-pll-clocks.patch clk-socfpga-stratix10-fix-naming-convention-for-the-fixed-clocks.patch inotify-fix-fd-refcount-leak-in-inotify_add_watch.patch alsa-hda-realtek-fix-typo-for-alc225-model.patch alsa-hda-add-mute-led-support-for-hp-probook-470-g5.patch arcv2-lib-memeset-fix-doing-prefetchw-outside-of-buffer.patch arc-adjust-memblock_reserve-of-kernel-memory.patch arc-perf-map-generic-branches-to-correct-hardware-condition.patch s390-vdso-correct-vdso-mapping-for-compat-tasks.patch s390-mm-always-force-a-load-of-the-primary-asce-on-context-switch.patch s390-early-improve-machine-detection.patch s390-smp-fix-cpu-hotplug-deadlock-with-cpu-rescan.patch s390-smp-fix-calling-smp_call_ipl_cpu-from-ipl-cpu.patch misc-ibmvsm-fix-potential-null-pointer-dereference.patch char-mwave-fix-potential-spectre-v1-vulnerability.patch mmc-sdhci-iproc-handle-mmc_of_parse-errors-during-probe.patch mmc-dw_mmc-bluefield-fix-the-license-information.patch mmc-meson-gx-free-irq-in-release-callback.patch staging-rtl8188eu-add-device-code-for-d-link-dwa-121-rev-b1.patch tty-handle-problem-if-line-discipline-does-not-have-receive_buf.patch uart-fix-crash-in-uart_write-and-uart_put_char.patch tty-n_hdlc-fix-__might_sleep-warning.patch hv_balloon-avoid-touching-uninitialized-struct-page-during-tail-onlining.patch drivers-hv-vmbus-check-for-ring-when-getting-debug-info.patch vgacon-unconfuse-vc_origin-when-using-soft-scrollback.patch cifs-fix-possible-hang-during-async-mtu-reads-and-writes.patch cifs-fix-credits-calculations-for-reads-with-errors.patch cifs-fix-credit-calculation-for-encrypted-reads-with-errors.patch cifs-do-not-reconnect-tcp-session-in-add_credits.patch smb3-add-credits-we-receive-from-oplock-break-pdus.patch input-xpad-add-support-for-steelseries-stratus-duo.patch input-input_event-provide-override-for-sparc64.patch input-uinput-fix-undefined-behavior-in-uinput_validate_absinfo.patch acpi-nfit-block-function-zero-dsms.patch acpi-nfit-fix-command-supported-detection.patch scsi-ufs-use-explicit-access-size-in-ufshcd_dump_regs.patch dm-thin-fix-passdown_double_checking_shared_status.patch dm-crypt-fix-parsing-of-extended-iv-arguments.patch drm-amdgpu-add-aptx-quirk-for-lenovo-laptop.patch edac-altera-fix-s10-persistent-register-offset.patch kvm-x86-fix-single-step-debugging.patch kvm-x86-fix-pv-ipis-for-32-bit-kvm-host.patch kvm-x86-warn_once-if-sending-a-pv-ipi-returns-a-fatal-error.patch kvm-x86-vmx-use-kzalloc-for-cached_vmcs12.patch x86-pkeys-properly-copy-pkey-state-at-fork.patch x86-selftests-pkeys-fork-to-check-for-state-being-preserved.patch x86-kaslr-fix-incorrect-i8254-outb-parameters.patch x86-entry-64-compat-fix-stack-switching-for-xen-pv.patch posix-cpu-timers-unbreak-timer-rearming.patch net-sun-cassini-cleanup-license-conflict.patch irqchip-gic-v3-its-align-pci-multi-msi-allocation-on-their-size.patch can-dev-__can_get_echo_skb-fix-bogous-check-for-non-existing-skb-by-removing-it.patch can-bcm-check-timer-values-before-ktime-conversion.patch can-flexcan-fix-null-pointer-exception-during-bringup.patch vt-make-vt_console_print-compatible-with-the-unicode-screen-buffer.patch vt-always-call-notifier-with-the-console-lock-held.patch vt-invoke-notifier-on-screen-size-change.patch drm-meson-fix-atomic-mode-switching-regression.patch Compile testing --------------- We compiled the kernel for 4 architectures: powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/0bcf75d067e11bab66cb635da9… s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/f137b3c0e426bab253e2332931de… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/0bd7f3a1cb649a63f6f0c4cd30… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/42f517be5ad60afbedcb5200199… Hardware testing ---------------- We booted each kernel and ran the following tests: powerpc: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 8 months

2
2
0 0

[PATCH] perf/x86/intel/uncore: Add Node ID mask

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> Some PCI uncore PMUs cannot be registered on a 8-socket system (HPE Superdome Flex). To understand which Socket the PCI uncore PMUs belong to, perf retrieves the local Node ID of the uncore device from CPUNODEID(0xC0) of the PCI configuration space, and the mapping between Socket ID and Node ID from GIDNIDMAP(0xD4). The Socket ID can be calculated accordingly. The local Node ID is only available at bit 2:0, but current code doesn't mask it. If a BIOS doesn't clear the rest of the bits, a wrong Node ID will be fetched. Filter the Node ID by adding a mask. Fixes: 7c94ee2e0917 ("perf/x86: Add Intel Nehalem and Sandy Bridge-EP uncore support") Reported-by: Song Liu <songliubraving(a)fb.com> Tested-by: Song Liu <songliubraving(a)fb.com> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/uncore_snbep.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index c07bee3..b10e043 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -1222,6 +1222,8 @@ static struct pci_driver snbep_uncore_pci_driver = { .id_table = snbep_uncore_pci_ids, }; +#define NODE_ID_MASK 0x7 + /* * build pci bus to socket mapping */ @@ -1243,7 +1245,7 @@ static int snbep_pci2phy_map_init(int devid, int nodeid_loc, int idmap_loc, bool err = pci_read_config_dword(ubox_dev, nodeid_loc, &config); if (err) break; - nodeid = config; + nodeid = config & NODE_ID_MASK; /* get the Node ID mapping */ err = pci_read_config_dword(ubox_dev, idmap_loc, &config); if (err) -- 2.7.4

6 years, 8 months

2
1
0 0

[PATCH] nfit: Fix nfit_intel_shutdown_status() command submission

by Dan Williams

The implementation is broken in all the ways the unit test did not touch: 1/ The local definition of in_buf and in_obj violated C99 initializer expectations for zeroing. By only initializing 2 out of the three struct members the compiler was free to zero-initialize the remaining entry even though the aliased location in the union was initialized. 2/ The implementation made assumptions about the state of the 'smart' payload after command execution that are satisfied by acpi_nfit_ctl(), but not acpi_evaluate_dsm(). 3/ populate_shutdown_status() is skipped on Intel NVDIMMs due to the early return for skipping the common _LS{I,R,W} enabling. 4/ The input length should be zero. This breakage was missed due to the unit test implementation only testing the case where nfit_intel_shutdown_status() returns a valid payload. Much of this complexity would be saved if acpi_nfit_ctl() could be used, but that currently requires a 'struct nvdimm *' argument and one is not created until later in the init process. The health result is needed before the device is created because the payload gates whether the nmemX/nfit/dirty_shutdown property is visible in sysfs. Cc: <stable(a)vger.kernel.org> Fixes: 0ead11181fe0 ("acpi, nfit: Collect shutdown status") Reported-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- drivers/acpi/nfit/core.c | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c index e18ade5d74e9..0a49c57334cc 100644 --- a/drivers/acpi/nfit/core.c +++ b/drivers/acpi/nfit/core.c @@ -1759,14 +1759,14 @@ static bool acpi_nvdimm_has_method(struct acpi_device *adev, char *method) __weak void nfit_intel_shutdown_status(struct nfit_mem *nfit_mem) { + struct device *dev = &nfit_mem->adev->dev; struct nd_intel_smart smart = { 0 }; union acpi_object in_buf = { - .type = ACPI_TYPE_BUFFER, - .buffer.pointer = (char *) &smart, - .buffer.length = sizeof(smart), + .buffer.type = ACPI_TYPE_BUFFER, + .buffer.length = 0, }; union acpi_object in_obj = { - .type = ACPI_TYPE_PACKAGE, + .package.type = ACPI_TYPE_PACKAGE, .package.count = 1, .package.elements = &in_buf, }; @@ -1781,8 +1781,15 @@ __weak void nfit_intel_shutdown_status(struct nfit_mem *nfit_mem) return; out_obj = acpi_evaluate_dsm(handle, guid, revid, func, &in_obj); - if (!out_obj) + if (!out_obj || out_obj->type != ACPI_TYPE_BUFFER + || out_obj->buffer.length < sizeof(smart)) { + dev_dbg(dev->parent, "%s: failed to retrieve initial health\n", + dev_name(dev)); + ACPI_FREE(out_obj); return; + } + memcpy(&smart, out_obj->buffer.pointer, sizeof(smart)); + ACPI_FREE(out_obj); if (smart.flags & ND_INTEL_SMART_SHUTDOWN_VALID) { if (smart.shutdown_state) @@ -1793,7 +1800,6 @@ __weak void nfit_intel_shutdown_status(struct nfit_mem *nfit_mem) set_bit(NFIT_MEM_DIRTY_COUNT, &nfit_mem->flags); nfit_mem->dirty_shutdown = smart.shutdown_count; } - ACPI_FREE(out_obj); } static void populate_shutdown_status(struct nfit_mem *nfit_mem) @@ -1915,18 +1921,19 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc *acpi_desc, | 1 << ND_CMD_SET_CONFIG_DATA; if (family == NVDIMM_FAMILY_INTEL && (dsm_mask & label_mask) == label_mask) - return 0; - - if (acpi_nvdimm_has_method(adev_dimm, "_LSI") - && acpi_nvdimm_has_method(adev_dimm, "_LSR")) { - dev_dbg(dev, "%s: has _LSR\n", dev_name(&adev_dimm->dev)); - set_bit(NFIT_MEM_LSR, &nfit_mem->flags); - } + /* skip _LS{I,R,W} enabling */; + else { + if (acpi_nvdimm_has_method(adev_dimm, "_LSI") + && acpi_nvdimm_has_method(adev_dimm, "_LSR")) { + dev_dbg(dev, "%s: has _LSR\n", dev_name(&adev_dimm->dev)); + set_bit(NFIT_MEM_LSR, &nfit_mem->flags); + } - if (test_bit(NFIT_MEM_LSR, &nfit_mem->flags) - && acpi_nvdimm_has_method(adev_dimm, "_LSW")) { - dev_dbg(dev, "%s: has _LSW\n", dev_name(&adev_dimm->dev)); - set_bit(NFIT_MEM_LSW, &nfit_mem->flags); + if (test_bit(NFIT_MEM_LSR, &nfit_mem->flags) + && acpi_nvdimm_has_method(adev_dimm, "_LSW")) { + dev_dbg(dev, "%s: has _LSW\n", dev_name(&adev_dimm->dev)); + set_bit(NFIT_MEM_LSW, &nfit_mem->flags); + } } populate_shutdown_status(nfit_mem);

6 years, 8 months

2
1
0 0

[PATCH] PCI: dwc: Fix stop condition on __dw_pcie_ep_find_next_cap()

by Gustavo Pimentel

The combination of __dw_pcie_ep_find_next_cap() and dw_pcie_ep_find_capability() allows to search on the Endpoint configuration space for a specific capability ID. This search is done recursively by __dw_pcie_ep_find_next_cap() jumping from capability to capability (using the next offset register to calculate next jump address), stopping until the next offset register is null or the current capability meets the desired ID. However, if the desired capability is at the end of that list, the recursive search will be returning because the next offset will be null (thus filling the first stop condition) and not because it has reached the desired ID and therefore reporting capability "not found". This fix will swap the stop conditions order of __dw_pcie_ep_find_next_cap(), allowing to find the desired capability ID, if it encounters at the end of the list. Fixes: beb4641a787d ("PCI: dwc: Add MSI-X callbacks handler") Reported-by: Jian Wang <jianwang(a)ra.rockwell.com> Signed-off-by: Gustavo Pimentel <gustavo.pimentel(a)synopsys.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Cc: Kishon Vijay Abraham I <kishon(a)ti.com> Cc: stable(a)vger.kernel.org --- drivers/pci/controller/dwc/pcie-designware-ep.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index a543c45..0258894 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -50,12 +50,12 @@ static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie *pci, u8 cap_ptr, next_cap_ptr = (reg & 0xff00) >> 8; cap_id = (reg & 0x00ff); - if (!next_cap_ptr || cap_id > PCI_CAP_ID_MAX) - return 0; - if (cap_id == cap) return cap_ptr; + if (!next_cap_ptr || cap_id > PCI_CAP_ID_MAX) + return 0; + return __dw_pcie_ep_find_next_cap(pci, next_cap_ptr, cap); } -- 2.7.4

6 years, 8 months

2
1
0 0

Re: [PATCH] kprobe: safely access memory specified by userspace

by Changbin Du

Hi, Please hold until Steven returned from Linux Conf Au. Thanks! On Tue, Jan 29, 2019 at 12:35:20AM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96, v4.9.153, v4.4.172, v3.18.133. > > v4.20.5: Build OK! > v4.19.18: Failed to apply! Possible dependencies: > 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") > 56de76305279 ("tracing: probeevent: Cleanup print argument functions") > 9178412ddf5a ("tracing: probeevent: Return consumed bytes of dynamic area") > > v4.14.96: Failed to apply! Possible dependencies: > 45408c4f9250 ("tracing: kprobes: Prohibit probing on notrace function") > 4bebdc7a85aa ("bpf: add helper bpf_perf_prog_read_value") > 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") > 908432ca84fc ("bpf: add helper bpf_perf_event_read_value for perf event array map") > 97562633bcba ("bpf: perf event change needed for subsequent bpf helpers") > 9802d86585db ("bpf: add a bpf_override_function helper") > b4da3340eae2 ("tracing/kprobe: bpf: Check error injectable event is on function entry") > cd86d1fd2102 ("bpf: Adding helper function bpf_getsockops") > dd0bb688eaa2 ("bpf: add a bpf_override_function helper") > de8f3a83b0a0 ("bpf: add meta pointer for direct access") > f3edacbd697f ("bpf: Revert bpf_overrid_function() helper changes.") > > v4.9.153: Failed to apply! Possible dependencies: > 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog") > 1d9995771fcb ("s390: update defconfigs") > 23a4e389bdc7 ("nfp: create separate define for max number of vectors") > 416db5c1e448 ("nfp: remove support for nfp3200") > 45408c4f9250 ("tracing: kprobes: Prohibit probing on notrace function") > 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") > 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme") > 68453c7a8973 ("nfp: centralize runtime reconfiguration logic") > 6b0b7551428e ("perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS") > 7ff5c83a1deb ("nfp: simplify nfp_net_poll()") > 9802d86585db ("bpf: add a bpf_override_function helper") > a4b562bb8ebd ("nfp: use unsigned int for vector/ring counts") > b4da3340eae2 ("tracing/kprobe: bpf: Check error injectable event is on function entry") > bf187ea01b07 ("nfp: centralize the buffer size calculation") > cbeaf7aa733a ("nfp: bring back support for different ring counts") > ccc109b8ed24 ("net/mlx4_en: Add TX_XDP for CQ types") > dd0bb688eaa2 ("bpf: add a bpf_override_function helper") > e390b55d5aef ("bpf: make bpf_xdp_adjust_head support mandatory") > ecd63a0217d5 ("nfp: add XDP support in the driver") > f18f97ac43d7 ("tracing/kprobes: Add a helper method to return number of probe hits") > f3edacbd697f ("bpf: Revert bpf_overrid_function() helper changes.") > > v4.4.172: Failed to apply! Possible dependencies: > 1d9995771fcb ("s390: update defconfigs") > 45408c4f9250 ("tracing: kprobes: Prohibit probing on notrace function") > 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") > 6b0b7551428e ("perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS") > 6e127efeeae5 ("s390/config: make the vector optimized crc function builtin") > a086171ad886 ("s390: Updated kernel config files") > cb14def6a9ca ("s390/configs: update default configurations") > e9bc15f28e5f ("s390/config: update default configuration") > fdcebf6f18ee ("s390/config: Enable config options for Docker") > > v3.18.133: Failed to apply! Possible dependencies: > 1a6877b9c0c2 ("lib: introduce strncpy_from_unsafe()") > 34c0dad75229 ("s390/hypfs: Add diagnose 0c support") > 45408c4f9250 ("tracing: kprobes: Prohibit probing on notrace function") > 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") > 5a79859ae0f3 ("s390: remove 31 bit support") > 5c6497c50f8d ("s390/jump label: add sanity checks") > 6b0b7551428e ("perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS") > 8461b63ca01d ("s390: translate cputime magic constants to macros") > a763bc8b656d ("s390/numa: enable support in s390 configs") > c07af4f1ce41 ("mm: add missing __PAGETABLE_{PUD,PMD}_FOLDED defines") > c933146a5e41 ("s390/ftrace,kprobes: allow to patch first instruction") > d5caa4dbf9bd ("s390/jump label: use different nop instruction") > e9bc15f28e5f ("s390/config: update default configuration") > f8b2dcbd9e6d ("s390: add z13 code generation support") > > > How should we proceed with this patch? > > -- > Thanks, > Sasha -- Cheers, Changbin Du

6 years, 8 months

1
0
0 0

+ mm-proc-smaps_rollup-fix-pss_locked-calculation.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: fs/proc/task_mmu.c: fix smaps_rollup pss_locked calculation has been added to the -mm tree. Its filename is mm-proc-smaps_rollup-fix-pss_locked-calculation.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-proc-smaps_rollup-fix-pss_locke… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-proc-smaps_rollup-fix-pss_locke… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Sandeep Patil <sspatil(a)android.com> Subject: fs/proc/task_mmu.c: fix smaps_rollup pss_locked calculation The 'pss_locked' field of smaps_rollup was being calculated incorrectly as it accumulated the current pss everytime a locked VMA was found. Fix that by making sure we record the current pss value before each VMA is walked. So, we can only add the delta if the VMA was found to be VM_LOCKED. Link: http://lkml.kernel.org/r/20190121011049.160505-1-sspatil@android.com Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup") Signed-off-by: Sandeep Patil <sspatil(a)android.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Andrey Vagin <avagin(a)openvz.org> Cc: Daniel Colascione <dancol(a)google.com> Cc: <stable(a)vger.kernel.org> [4.14.x 4.19.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/fs/proc/task_mmu.c~mm-proc-smaps_rollup-fix-pss_locked-calculation +++ a/fs/proc/task_mmu.c @@ -721,6 +721,7 @@ static void smap_gather_stats(struct vm_ #endif .mm = vma->vm_mm, }; + unsigned long pss; smaps_walk.private = mss; @@ -749,11 +750,12 @@ static void smap_gather_stats(struct vm_ } } #endif - + /* record current pss so we can calculate the delta after page walk */ + pss = mss->pss; /* mmap_sem is held in m_start */ walk_page_vma(vma, &smaps_walk); if (vma->vm_flags & VM_LOCKED) - mss->pss_locked += mss->pss; + mss->pss_locked += mss->pss - pss; } #define SEQ_PUT_DEC(str, val) \ _ Patches currently in -mm which might be from sspatil(a)android.com are mm-proc-smaps_rollup-fix-pss_locked-calculation.patch

6 years, 8 months

1
0
0 0

+ mm-oom-fix-use-after-free-in-oom_kill_process.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, oom: fix use-after-free in oom_kill_process has been added to the -mm tree. Its filename is mm-oom-fix-use-after-free-in-oom_kill_process.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-oom-fix-use-after-free-in-oom_k… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-oom-fix-use-after-free-in-oom_k… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Shakeel Butt <shakeelb(a)google.com> Subject: mm, oom: fix use-after-free in oom_kill_process Syzbot instance running on upstream kernel found a use-after-free bug in oom_kill_process. On further inspection it seems like the process selected to be oom-killed has exited even before reaching read_lock(&tasklist_lock) in oom_kill_process(). More specifically the tsk->usage is 1 which is due to get_task_struct() in oom_evaluate_task() and the put_task_struct within for_each_thread() frees the tsk and for_each_thread() tries to access the tsk. The easiest fix is to do get/put across the for_each_thread() on the selected task. Now the next question is should we continue with the oom-kill as the previously selected task has exited? However before adding more complexity and heuristics, let's answer why we even look at the children of oom-kill selected task? The select_bad_process() has already selected the worst process in the system/memcg. Due to race, the selected process might not be the worst at the kill time but does that matter? The userspace can use the oom_score_adj interface to prefer children to be killed before the parent. I looked at the history but it seems like this is there before git history. Link: http://lkml.kernel.org/r/20190121215850.221745-1-shakeelb@google.com Reported-by: syzbot+7fbbfa368521945f0e3d(a)syzkaller.appspotmail.com Fixes: 6b0c81b3be11 ("mm, oom: reduce dependency on tasklist_lock") Signed-off-by: Shakeel Butt <shakeelb(a)google.com> Reviewed-by: Roman Gushchin <guro(a)fb.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/oom_kill.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/mm/oom_kill.c~mm-oom-fix-use-after-free-in-oom_kill_process +++ a/mm/oom_kill.c @@ -975,6 +975,13 @@ static void oom_kill_process(struct oom_ * still freeing memory. */ read_lock(&tasklist_lock); + + /* + * The task 'p' might have already exited before reaching here. The + * put_task_struct() will free task_struct 'p' while the loop still try + * to access the field of 'p', so, get an extra reference. + */ + get_task_struct(p); for_each_thread(p, t) { list_for_each_entry(child, &t->children, sibling) { unsigned int child_points; @@ -994,6 +1001,7 @@ static void oom_kill_process(struct oom_ } } } + put_task_struct(p); read_unlock(&tasklist_lock); /* _ Patches currently in -mm which might be from shakeelb(a)google.com are mm-oom-fix-use-after-free-in-oom_kill_process.patch memcg-localize-memcg_kmem_enabled-check.patch memcg-schedule-high-reclaim-for-remote-memcgs-on-high_work.patch memcg-schedule-high-reclaim-for-remote-memcgs-on-high_work-v3.patch mm-oom-remove-prefer-children-over-parent-heuristic.patch

6 years, 8 months

1
0
0 0

[PATCH] Fix: membarrier: racy access to p->mm in membarrier_global_expedited()

by Mathieu Desnoyers

Jann Horn identified a racy access to p->mm in the global expedited command of the membarrier system call. The suggested fix is to hold the task_lock() around the accesses to p->mm and to the mm_struct membarrier_state field to guarantee the existence of the mm_struct. Link: https://lore.kernel.org/lkml/CAG48ez2G8ctF8dHS42TF37pThfr3y0RNOOYTmxvACm4u8… Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Tested-by: Jann Horn <jannh(a)google.com> CC: Jann Horn <jannh(a)google.com> CC: Thomas Gleixner <tglx(a)linutronix.de> CC: Peter Zijlstra (Intel) <peterz(a)infradead.org> CC: Ingo Molnar <mingo(a)kernel.org> CC: Andrea Parri <parri.andrea(a)gmail.com> CC: Andy Lutomirski <luto(a)kernel.org> CC: Avi Kivity <avi(a)scylladb.com> CC: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> CC: Boqun Feng <boqun.feng(a)gmail.com> CC: Dave Watson <davejwatson(a)fb.com> CC: David Sehr <sehr(a)google.com> CC: H. Peter Anvin <hpa(a)zytor.com> CC: Linus Torvalds <torvalds(a)linux-foundation.org> CC: Maged Michael <maged.michael(a)gmail.com> CC: Michael Ellerman <mpe(a)ellerman.id.au> CC: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> CC: Paul Mackerras <paulus(a)samba.org> CC: Russell King <linux(a)armlinux.org.uk> CC: Will Deacon <will.deacon(a)arm.com> CC: stable(a)vger.kernel.org # v4.16+ CC: linux-api(a)vger.kernel.org --- kernel/sched/membarrier.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c index 76e0eaf4654e..305fdcc4c5f7 100644 --- a/kernel/sched/membarrier.c +++ b/kernel/sched/membarrier.c @@ -81,12 +81,27 @@ static int membarrier_global_expedited(void) rcu_read_lock(); p = task_rcu_dereference(&cpu_rq(cpu)->curr); - if (p && p->mm && (atomic_read(&p->mm->membarrier_state) & - MEMBARRIER_STATE_GLOBAL_EXPEDITED)) { - if (!fallback) - __cpumask_set_cpu(cpu, tmpmask); - else - smp_call_function_single(cpu, ipi_mb, NULL, 1); + /* + * Skip this CPU if the runqueue's current task is NULL or if + * it is a kernel thread. + */ + if (p && READ_ONCE(p->mm)) { + bool mm_match; + + /* + * Read p->mm and access membarrier_state while holding + * the task lock to ensure existence of mm. + */ + task_lock(p); + mm_match = p->mm && (atomic_read(&p->mm->membarrier_state) & + MEMBARRIER_STATE_GLOBAL_EXPEDITED); + task_unlock(p); + if (mm_match) { + if (!fallback) + __cpumask_set_cpu(cpu, tmpmask); + else + smp_call_function_single(cpu, ipi_mb, NULL, 1); + } } rcu_read_unlock(); } -- 2.17.1

6 years, 8 months

3
4
0 0

+ mmmemory_hotplug-fix-scan_movable_pages-for-gigantic-hugepages.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages has been added to the -mm tree. Its filename is mmmemory_hotplug-fix-scan_movable_pages-for-gigantic-hugepages.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mmmemory_hotplug-fix-scan_movable_… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mmmemory_hotplug-fix-scan_movable_… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Oscar Salvador <osalvador(a)suse.de> Subject: mm,memory_hotplug: fix scan_movable_pages() for gigantic hugepages This is the same sort of error we saw in 17e2e7d7e1b83 ("mm, page_alloc: fix has_unmovable_pages for HugePages"). Gigantic hugepages cross several memblocks, so it can be that the page we get in scan_movable_pages() is a page-tail belonging to a 1G-hugepage. If that happens, page_hstate()->size_to_hstate() will return NULL, and we will blow up in hugepage_migration_supported(). The splat is as follows: kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 kernel: #PF error: [normal kernel read fault] kernel: PGD 0 P4D 0 kernel: Oops: 0000 [#1] SMP PTI kernel: CPU: 1 PID: 1350 Comm: bash Tainted: G E 5.0.0-rc1-mm1-1-default+ #27 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 kernel: RIP: 0010:__offline_pages+0x6ae/0x900 kernel: Code: 48 c7 c6 d0 3e a4 81 e8 44 c8 ad ff 49 8b 04 24 bf 00 10 00 00 a9 00 00 01 00 74 09 41 0f b6 4c 24 51 48 d3 e7 e8 42 2a c1 ff <8b> 40 08 83 f8 09 0f 84 b0 fc ff ff 83 f8 12 0f 84 a7 fc ff ff 83 kernel: RSP: 0018:ffffc900008e3d20 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffffea0000000000 RCX: 0000000000000009 kernel: RDX: ffffffff825c64f0 RSI: 0000000000001000 RDI: 0000000000001000 kernel: RBP: ffffc900008e3d68 R08: 0000000000200000 R09: 00000000000001e4 kernel: R10: 0000000000000058 R11: ffffffff8254a854 R12: ffffea0004200000 kernel: R13: 0000000000108000 R14: 0000000000110000 R15: 0000000000000000 kernel: FS: 00007ff172339b80(0000) GS:ffff88803eb00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000008 CR3: 0000000038d78006 CR4: 00000000003606a0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 kernel: Call Trace: kernel: ? klist_next+0x79/0xe0 kernel: memory_subsys_offline+0x42/0x60 kernel: device_offline+0x80/0xa0 kernel: state_store+0xab/0xc0 kernel: kernfs_fop_write+0x102/0x180 kernel: __vfs_write+0x26/0x190 kernel: ? set_close_on_exec+0x49/0x70 kernel: vfs_write+0xad/0x1b0 kernel: ksys_write+0x42/0x90 kernel: do_syscall_64+0x5b/0x180 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel: RIP: 0033:0x7ff1719febe4 kernel: Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a fc 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83 kernel: RSP: 002b:00007ffd50b7ddc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 kernel: RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007ff1719febe4 kernel: RDX: 0000000000000008 RSI: 00005556e9216b20 RDI: 0000000000000001 kernel: RBP: 00005556e9216b20 R08: 000000000000000a R09: 0000000000000000 kernel: R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000008 kernel: R13: 0000000000000001 R14: 00007ff171cca720 R15: 0000000000000008 kernel: Modules linked in: af_packet(E) xt_tcpudp(E) ipt_REJECT(E) xt_conntrack(E) nf_conntrack(E) nf_defrag_ipv4(E) ip_set(E) nfnetlink(E) ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ebtable_filter(E) ebtables(E) iptable_filter(E) ip_tables(E) x_tables(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) bochs_drm(E) ttm(E) aesni_intel(E) drm_kms_helper(E) aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) drm(E) virtio_net(E) syscopyarea(E) sysfillrect(E) net_failover(E) sysimgblt(E) pcspkr(E) failover(E) i2c_piix4(E) fb_sys_fops(E) parport_pc(E) parport(E) button(E) btrfs(E) libcrc32c(E) xor(E) zstd_decompress(E) zstd_compress(E) xxhash(E) raid6_pq(E) sd_mod(E) ata_generic(E) ata_piix(E) ahci(E) libahci(E) libata(E) crc32c_intel(E) serio_raw(E) virtio_pci(E) virtio_ring(E) virtio(E) sg(E) scsi_mod(E) autofs4(E) kernel: CR2: 0000000000000008 kernel: ---[ end trace bdb71590872849fb ]--- kernel: RIP: 0010:__offline_pages+0x6ae/0x900 kernel: Code: 48 c7 c6 d0 3e a4 81 e8 44 c8 ad ff 49 8b 04 24 bf 00 10 00 00 a9 00 00 01 00 74 09 41 0f b6 4c 24 51 48 d3 e7 e8 42 2a c1 ff <8b> 40 08 83 f8 09 0f 84 b0 fc ff ff 83 f8 12 0f 84 a7 fc ff ff 83 kernel: RSP: 0018:ffffc900008e3d20 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffffea0000000000 RCX: 0000000000000009 kernel: RDX: ffffffff825c64f0 RSI: 0000000000001000 RDI: 0000000000001000 kernel: RBP: ffffc900008e3d68 R08: 0000000000200000 R09: 00000000000001e4 kernel: R10: 0000000000000058 R11: ffffffff8254a854 R12: ffffea0004200000 kernel: R13: 0000000000108000 R14: 0000000000110000 R15: 0000000000000000 kernel: FS: 00007ff172339b80(0000) GS:ffff88803eb00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000008 CR3: 0000000038d78006 CR4: 00000000003606a0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Link: http://lkml.kernel.org/r/20190122154407.18417-1-osalvador@suse.de Signed-off-by: Oscar Salvador <osalvador(a)suse.de> Reviewed-by: Anthony Yznaga <anthony.yznaga(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory_hotplug.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) --- a/mm/memory_hotplug.c~mmmemory_hotplug-fix-scan_movable_pages-for-gigantic-hugepages +++ a/mm/memory_hotplug.c @@ -1314,12 +1314,17 @@ static unsigned long scan_movable_pages( if (__PageMovable(page)) return pfn; if (PageHuge(page)) { - if (hugepage_migration_supported(page_hstate(page)) && - page_huge_active(page)) + struct page *head = compound_head(page); + + if (hugepage_migration_supported(page_hstate(head)) && + page_huge_active(head)) return pfn; - else - pfn = round_up(pfn + 1, - 1 << compound_order(page)) - 1; + else { + unsigned long skip; + + skip = (1 << compound_order(head)) - (page - head); + pfn += skip - 1; + } } } } _ Patches currently in -mm which might be from osalvador(a)suse.de are mm-memory_hotplug-dont-bail-out-in-do_migrate_range-prematurely.patch mmmemory_hotplug-fix-scan_movable_pages-for-gigantic-hugepages.patch

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] vmbus: fix subchannel removal" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From b5679cebf780c6f1c2451a73bf1842a4409840e7 Mon Sep 17 00:00:00 2001 From: Dexuan Cui <decui(a)microsoft.com> Date: Wed, 9 Jan 2019 20:56:06 +0000 Subject: [PATCH] vmbus: fix subchannel removal The changes to split ring allocation from open/close, broke the cleanup of subchannels. This resulted in problems using uio on network devices because the subchannel was left behind when the network device was unbound. The cause was in the disconnect logic which used list splice to move the subchannel list into a local variable. This won't work because the subchannel list is needed later during the process of the rescind messages (relid2channel). The fix is to just leave the subchannel list in place which is what the original code did. The list is cleaned up later when the host rescind is processed. Without the fix, we have a lot of "hang" issues in netvsc when we try to change the NIC's MTU, set the number of channels, etc. Fixes: ae6935ed7d42 ("vmbus: split ring buffer allocation from open") Cc: stable(a)vger.kernel.org Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index ce0ba2062723..bea4c9850247 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -701,19 +701,12 @@ static int vmbus_close_internal(struct vmbus_channel *channel) int vmbus_disconnect_ring(struct vmbus_channel *channel) { struct vmbus_channel *cur_channel, *tmp; - unsigned long flags; - LIST_HEAD(list); int ret; if (channel->primary_channel != NULL) return -EINVAL; - /* Snapshot the list of subchannels */ - spin_lock_irqsave(&channel->lock, flags); - list_splice_init(&channel->sc_list, &list); - spin_unlock_irqrestore(&channel->lock, flags); - - list_for_each_entry_safe(cur_channel, tmp, &list, sc_list) { + list_for_each_entry_safe(cur_channel, tmp, &channel->sc_list, sc_list) { if (cur_channel->rescind) wait_for_completion(&cur_channel->rescind_event);

6 years, 8 months

3
2
0 0

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 9f1a389a0b5b Linux 4.20.5 The results of these automated tests are provided below. Overall result: FAILED (see details below) Patch merge: OK Compile: OK Kernel tests: FAILED One or more kernel tests failed: powerpc64le: PASSED s390x: PASSED aarch64: PASSED x86_64: PASSED We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 9f1a389a0b5b Linux 4.20.5 We then merged the following patches with `git am`: amd-xgbe-fix-mdio-access-for-non-zero-ports-and-clause-45-phys.patch net-bridge-fix-ethernet-header-pointer-before-check-skb-forwardable.patch net-fix-usage-of-pskb_trim_rcsum.patch net-phy-marvell-errata-for-mv88e6390-internal-phys.patch net-phy-mdio_bus-add-missing-device_del-in-mdiobus_register-error-handling.patch net-phy-phy-driver-features-are-mandatory.patch net-sched-act_tunnel_key-fix-memory-leak-in-case-of-action-replace.patch net_sched-refetch-skb-protocol-for-each-filter.patch openvswitch-avoid-oob-read-when-parsing-flow-nlattrs.patch vhost-log-dirty-page-correctly.patch mlxsw-pci-increase-pci-sw-reset-timeout.patch net-ipv4-fix-memory-leak-in-network-namespace-dismantle.patch mlxsw-spectrum_fid-update-dummy-fid-index.patch mlxsw-pci-ring-cq-s-doorbell-before-rdq-s.patch net-sched-cls_flower-allocate-mask-dynamically-in-fl_change.patch udp-with-udp_segment-release-on-error-path.patch ip6_gre-fix-tunnel-list-corruption-for-x-netns.patch erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch net-phy-marvell-fix-deadlock-from-wrong-locking.patch ip6_gre-update-version-related-info-when-changing-link.patch tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch arm-fix-the-cockup-in-the-previous-patch.patch sunrpc-address-kerberos-performance-behavior-regress.patch mei-me-mark-lbg-devices-as-having-dma-support.patch mei-me-add-denverton-innovation-engine-device-ids.patch usb-leds-fix-regression-in-usbport-led-trigger.patch usb-ehci-ehci-mv-add-module_device_table.patch usb-serial-ftdi_sio-fix-gpio-not-working-in-autosuspend.patch usb-serial-simple-add-motorola-tetra-tpg2200-device-id.patch usb-serial-pl2303-add-new-pid-to-support-pl2303tb.patch ceph-clear-inode-pointer-when-snap-realm-gets-dropped-by-its-inode.patch asoc-atom-fix-a-missing-check-of-snd_pcm_lib_malloc_pages.patch asoc-rt5514-spi-fix-potential-null-pointer-dereference.patch asoc-tlv320aic32x4-kernel-oops-while-entering-dapm-standby-mode.patch clk-zynqmp-fix-memory-allocation-in-zynqmp_clk_setup.patch clk-socfpga-stratix10-fix-rate-calculation-for-pll-clocks.patch clk-socfpga-stratix10-fix-naming-convention-for-the-fixed-clocks.patch inotify-fix-fd-refcount-leak-in-inotify_add_watch.patch alsa-hda-realtek-fix-typo-for-alc225-model.patch alsa-hda-add-mute-led-support-for-hp-probook-470-g5.patch arcv2-lib-memeset-fix-doing-prefetchw-outside-of-buffer.patch arc-adjust-memblock_reserve-of-kernel-memory.patch arc-perf-map-generic-branches-to-correct-hardware-condition.patch s390-vdso-correct-vdso-mapping-for-compat-tasks.patch s390-mm-always-force-a-load-of-the-primary-asce-on-context-switch.patch s390-early-improve-machine-detection.patch s390-smp-fix-cpu-hotplug-deadlock-with-cpu-rescan.patch s390-smp-fix-calling-smp_call_ipl_cpu-from-ipl-cpu.patch misc-ibmvsm-fix-potential-null-pointer-dereference.patch char-mwave-fix-potential-spectre-v1-vulnerability.patch mmc-sdhci-iproc-handle-mmc_of_parse-errors-during-probe.patch mmc-dw_mmc-bluefield-fix-the-license-information.patch mmc-meson-gx-free-irq-in-release-callback.patch staging-rtl8188eu-add-device-code-for-d-link-dwa-121-rev-b1.patch tty-handle-problem-if-line-discipline-does-not-have-receive_buf.patch uart-fix-crash-in-uart_write-and-uart_put_char.patch tty-n_hdlc-fix-__might_sleep-warning.patch hv_balloon-avoid-touching-uninitialized-struct-page-during-tail-onlining.patch drivers-hv-vmbus-check-for-ring-when-getting-debug-info.patch vgacon-unconfuse-vc_origin-when-using-soft-scrollback.patch cifs-fix-possible-hang-during-async-mtu-reads-and-writes.patch cifs-fix-credits-calculations-for-reads-with-errors.patch cifs-fix-credit-calculation-for-encrypted-reads-with-errors.patch cifs-do-not-reconnect-tcp-session-in-add_credits.patch smb3-add-credits-we-receive-from-oplock-break-pdus.patch input-xpad-add-support-for-steelseries-stratus-duo.patch input-input_event-provide-override-for-sparc64.patch input-uinput-fix-undefined-behavior-in-uinput_validate_absinfo.patch acpi-nfit-block-function-zero-dsms.patch acpi-nfit-fix-command-supported-detection.patch scsi-ufs-use-explicit-access-size-in-ufshcd_dump_regs.patch dm-thin-fix-passdown_double_checking_shared_status.patch dm-crypt-fix-parsing-of-extended-iv-arguments.patch drm-amdgpu-add-aptx-quirk-for-lenovo-laptop.patch edac-altera-fix-s10-persistent-register-offset.patch kvm-x86-fix-single-step-debugging.patch kvm-x86-fix-pv-ipis-for-32-bit-kvm-host.patch kvm-x86-warn_once-if-sending-a-pv-ipi-returns-a-fatal-error.patch kvm-x86-vmx-use-kzalloc-for-cached_vmcs12.patch x86-pkeys-properly-copy-pkey-state-at-fork.patch x86-selftests-pkeys-fork-to-check-for-state-being-preserved.patch x86-kaslr-fix-incorrect-i8254-outb-parameters.patch x86-entry-64-compat-fix-stack-switching-for-xen-pv.patch posix-cpu-timers-unbreak-timer-rearming.patch net-sun-cassini-cleanup-license-conflict.patch irqchip-gic-v3-its-align-pci-multi-msi-allocation-on-their-size.patch can-dev-__can_get_echo_skb-fix-bogous-check-for-non-existing-skb-by-removing-it.patch can-bcm-check-timer-values-before-ktime-conversion.patch can-flexcan-fix-null-pointer-exception-during-bringup.patch vt-make-vt_console_print-compatible-with-the-unicode-screen-buffer.patch vt-always-call-notifier-with-the-console-lock-held.patch vt-invoke-notifier-on-screen-size-change.patch Compile testing --------------- We compiled the kernel for 4 architectures: powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/37ab853d978ad56fe7282effaf… s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/a46196bd00443d94448839972e96… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/ad27f389bdca6633caea1a474f… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/45a926f1b63beab12bfa2e5cd35… Hardware testing ---------------- We booted each kernel and ran the following tests: powerpc: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 8 months

1
0
0 0

[RFC PATCH] Fix: membarrier: racy access to p->mm in membarrier_global_expedited()

by Mathieu Desnoyers

Jann Horn identified a racy access to p->mm in the global expedited command of the membarrier system call. The suggested fix is to hold the task_lock() around the accesses to p->mm and to the mm_struct membarrier_state field to guarantee the existence of the mm_struct. Link: https://lore.kernel.org/lkml/CAG48ez2G8ctF8dHS42TF37pThfr3y0RNOOYTmxvACm4u8… Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> CC: Jann Horn <jannh(a)google.com> CC: Thomas Gleixner <tglx(a)linutronix.de> CC: Peter Zijlstra (Intel) <peterz(a)infradead.org> CC: Ingo Molnar <mingo(a)kernel.org> CC: Andrea Parri <parri.andrea(a)gmail.com> CC: Andrew Hunter <ahh(a)google.com> CC: Andy Lutomirski <luto(a)kernel.org> CC: Avi Kivity <avi(a)scylladb.com> CC: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> CC: Boqun Feng <boqun.feng(a)gmail.com> CC: Dave Watson <davejwatson(a)fb.com> CC: David Sehr <sehr(a)google.com> CC: Greg Hackmann <ghackmann(a)google.com> CC: H. Peter Anvin <hpa(a)zytor.com> CC: Linus Torvalds <torvalds(a)linux-foundation.org> CC: Maged Michael <maged.michael(a)gmail.com> CC: Michael Ellerman <mpe(a)ellerman.id.au> CC: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> CC: Paul Mackerras <paulus(a)samba.org> CC: Russell King <linux(a)armlinux.org.uk> CC: Will Deacon <will.deacon(a)arm.com> CC: stable(a)vger.kernel.org # v4.16+ CC: linux-api(a)vger.kernel.org --- kernel/sched/membarrier.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c index 76e0eaf4654e..305fdcc4c5f7 100644 --- a/kernel/sched/membarrier.c +++ b/kernel/sched/membarrier.c @@ -81,12 +81,27 @@ static int membarrier_global_expedited(void) rcu_read_lock(); p = task_rcu_dereference(&cpu_rq(cpu)->curr); - if (p && p->mm && (atomic_read(&p->mm->membarrier_state) & - MEMBARRIER_STATE_GLOBAL_EXPEDITED)) { - if (!fallback) - __cpumask_set_cpu(cpu, tmpmask); - else - smp_call_function_single(cpu, ipi_mb, NULL, 1); + /* + * Skip this CPU if the runqueue's current task is NULL or if + * it is a kernel thread. + */ + if (p && READ_ONCE(p->mm)) { + bool mm_match; + + /* + * Read p->mm and access membarrier_state while holding + * the task lock to ensure existence of mm. + */ + task_lock(p); + mm_match = p->mm && (atomic_read(&p->mm->membarrier_state) & + MEMBARRIER_STATE_GLOBAL_EXPEDITED); + task_unlock(p); + if (mm_match) { + if (!fallback) + __cpumask_set_cpu(cpu, tmpmask); + else + smp_call_function_single(cpu, ipi_mb, NULL, 1); + } } rcu_read_unlock(); } -- 2.17.1

6 years, 8 months

4
5
0 0

[PATCH stable 4.20 00/10] BPF stable fixes

by Daniel Borkmann

The following patches are targeted at 4.20 stable tree. Thanks! Daniel Borkmann (10): bpf: move {prev_,}insn_idx into verifier env bpf: move tmp variable into ax register in interpreter bpf: enable access to ax register also from verifier rewrite bpf: restrict map value pointer arithmetic for unprivileged bpf: restrict stack pointer arithmetic for unprivileged bpf: restrict unknown scalars of mixed signed bounds for unprivileged bpf: fix check_map_access smin_value test when pointer contains offset bpf: prevent out of bounds speculation on pointer arithmetic bpf: fix sanitation of alu op with pointer / scalar type from different paths bpf: fix inner map masking to prevent oob under speculation include/linux/bpf_verifier.h | 13 ++ include/linux/filter.h | 10 +- kernel/bpf/core.c | 54 +++-- kernel/bpf/map_in_map.c | 17 +- kernel/bpf/verifier.c | 369 +++++++++++++++++++++++++++++------ 5 files changed, 377 insertions(+), 86 deletions(-) -- 2.17.1

6 years, 8 months

2
11
0 0

[PATCH] drm/nouveau: Don't WARN_ON VCPI allocation failures

by Lyude Paul

This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: dri-devel(a)lists.freedesktop.org Cc: nouveau(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v4.10+ --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 2e8a5fd9b262..09a9c747c7bb 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -811,7 +811,8 @@ nv50_msto_enable(struct drm_encoder *encoder) slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn); r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn, slots); - WARN_ON(!r); + if (!r) + DRM_DEBUG_KMS("Failed to allocate VCPI\n"); if (!mstm->links++) nv50_outp_acquire(mstm->outp); -- 2.20.1

6 years, 8 months

1
0
0 0

[PATCH stable 4.19 00/12] BPF stable fixes

by Daniel Borkmann

The following patches are targeted at 4.19 stable tree. Thanks! Alexei Starovoitov (2): bpf: improve verifier branch analysis bpf: add per-insn complexity limit Daniel Borkmann (10): bpf: move {prev_,}insn_idx into verifier env bpf: move tmp variable into ax register in interpreter bpf: enable access to ax register also from verifier rewrite bpf: restrict map value pointer arithmetic for unprivileged bpf: restrict stack pointer arithmetic for unprivileged bpf: restrict unknown scalars of mixed signed bounds for unprivileged bpf: fix check_map_access smin_value test when pointer contains offset bpf: prevent out of bounds speculation on pointer arithmetic bpf: fix sanitation of alu op with pointer / scalar type from different paths bpf: fix inner map masking to prevent oob under speculation include/linux/bpf_verifier.h | 13 + include/linux/filter.h | 10 +- kernel/bpf/core.c | 54 ++-- kernel/bpf/map_in_map.c | 17 +- kernel/bpf/verifier.c | 470 +++++++++++++++++++++++++++++------ 5 files changed, 463 insertions(+), 101 deletions(-) -- 2.17.1

6 years, 8 months

1
12
0 0

Regression in v4.14.94 by "x86, kvm: move qemu/guest FPU switching out to vcpu_run"

by Thomas Lindroth

I run a qemu/kvm VM with debian and I've started getting segfaults and failing checksums on downloaded files. The failures are undeterministic and similar to the failures you get with bad ram. I tried to diagnose the problem with various testing tools and found that "stress-ng --verify --cpu 1" always give an error. Stress-ng give one of these errors usually within 60 sec: stress-ng-cpu: Newton-Rapshon sqrt not accurate enough stress-ng-cpu: prime error detected, number of primes between 0 and 1000000 miscalculated Nothing relevant has changed recently in the VM but the host kernel was upgraded from 4.14.93 to 4.14.96. I can't reproduce the stress-ng error with a 4.14.93 host kernel. There is only one kvm related change in that range so I tried to revert that one. By reverting commit 4124a4cff344abbf8187775eb643d9827830e715 "x86,kvm: move qemu/guest FPU switching out to vcpu_run" on kernel 4.14.96 I can't reproduce the stress-ng error and I have no segfault or other problems with the guest. The commit was originally introduced in v4.15-rc3 (Nov 14 2017) and was only recently backported to 4.14. The other stable kernels before 4.14 didn't get any backport so it looks like a broken 4.14 backport. That backport also cause problems for other people. https://bugzilla.kernel.org/show_bug.cgi?id=202419 I've rebooted between the different kernels and rebooted the VM enough to be reasonably sure that commit is the problem. Stress-ng never lasts more than 10 min with that commit but works for hours without it. Steps to reproduce would be to create a qemu/kvm VM with debian stretch, install stress-ng version 0.07.16 and run "stress-ng --verify --cpu 1". Here is the qemu-3.1.0 commandline generated by libvirt: /usr/bin/qemu-system-x86_64 -name guest=debian,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-debian/master-key.aes -machine pc-i440fx-2.4,accel=kvm,usb=off,dump-guest-core=off -cpu Haswell-noTSX -m 2048 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 0473ded4-d417-4b0e-a4f5-36ba5a2cd675 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=21,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -drive if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=2 -drive file=/mnt/gemini.61rn.3T/Backups/debian.raw,format=raw,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=23,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:11:22:33:44:55,bus=pci.0,addr=0x3 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x7 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on My host kernel .config is big so I put it in a paste: http://sprunge.us/u7YNBt

6 years, 8 months

3
3
0 0

[obsolete] mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: migrate: don't rely on PageMovable() of newpage after unlocking it has been removed from the -mm tree. Its filename was mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it.patch This patch was dropped because it is obsolete ------------------------------------------------------ From: David Hildenbrand <david(a)redhat.com> Subject: mm: migrate: don't rely on PageMovable() of newpage after unlocking it While debugging some crashes related to virtio-balloon deflation that happened under the old balloon migration code, I stumbled over a race that still exists today. What we experienced: drivers/virtio/virtio_balloon.c:release_pages_balloon(): - WARNING: CPU: 13 PID: 6586 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0 - list_del corruption. prev->next should be ffffe253961090a0, but was dead000000000100 Turns out after having added the page to a local list when dequeuing, the page would suddenly be moved to an LRU list before we would free it via the local list, corrupting both lists. So a page we own and that is !LRU was moved to an LRU list. In __unmap_and_move(), we lock the old and newpage and perform the migration. In case of vitio-balloon, the new page will become movable, the old page will no longer be movable. However, after unlocking newpage, there is nothing stopping the newpage from getting dequeued and freed by virtio-balloon. This will result in the newpage 1. No longer having PageMovable() 2. Getting moved to the local list before finally freeing it (using page->lru) Back in the migration thread in __unmap_and_move(), we would after unlocking the newpage suddenly no longer have PageMovable(newpage) and will therefore call putback_lru_page(newpage), modifying page->lru although that list is still in use by virtio-balloon. To summarize, we have a race between migrating the newpage and checking for PageMovable(newpage). Instead of checking PageMovable(newpage), we can simply rely on is_lru of the original page. Looks like this was introduced by d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management"), which was backported up to 3.12. Old compaction code used PageBalloon() via -_is_movable_balloon_page() instead of PageMovable(), however with the same semantics. Link: http://lkml.kernel.org/r/20190128160403.16657-1-david@redhat.com Fixes: d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management") Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: Vratislav Bendel <vbendel(a)redhat.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Rafael Aquini <aquini(a)redhat.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Jan Kara <jack(a)suse.cz> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Dominik Brodowski <linux(a)dominikbrodowski.net> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Konstantin Khlebnikov <k.khlebnikov(a)samsung.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: <stable(a)vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/migrate.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/mm/migrate.c~mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it +++ a/mm/migrate.c @@ -1135,10 +1135,12 @@ out: * If migration is successful, decrease refcount of the newpage * which will not free the page because new page owner increased * refcounter. As well, if it is LRU page, add the page to LRU - * list in here. + * list in here. Don't rely on PageMovable(newpage), as that could + * already have changed after unlocking newpage (e.g. + * virtio-balloon deflation). */ if (rc == MIGRATEPAGE_SUCCESS) { - if (unlikely(__PageMovable(newpage))) + if (unlikely(!is_lru)) put_page(newpage); else putback_lru_page(newpage); _ Patches currently in -mm which might be from david(a)redhat.com are mm-balloon-update-comment-about-isolation-migration-compaction.patch mm-convert-pg_balloon-to-pg_offline.patch kexec-export-pg_offline-to-vmcoreinfo.patch xen-balloon-mark-inflated-pages-pg_offline.patch hv_balloon-mark-inflated-pages-pg_offline.patch vmw_balloon-mark-inflated-pages-pg_offline.patch vmw_balloon-mark-inflated-pages-pg_offline-v2.patch pm-hibernate-use-pfn_to_online_page.patch pm-hibernate-exclude-all-pageoffline-pages.patch pm-hibernate-exclude-all-pageoffline-pages-v2.patch

6 years, 8 months

1
0
0 0

4.14 revert "seccomp: add a selftest for get_metadata"

by Rantala, Tommi T. (Nokia - FI/Espoo)

Hi Greg, Can you please revert this commit in 4.14? commit e65cd9a20343ea90f576c24c38ee85ab6e7d5fec Author: Tycho Andersen <tycho(a)tycho.ws> Date: Tue Feb 20 19:47:47 2018 -0700 seccomp: add a selftest for get_metadata [ Upstream commit d057dc4e35e16050befa3dda943876dab39cbf80 ] Let's test that we get the flags correctly, and that we preserve the filter index across the ptrace(PTRACE_SECCOMP_GET_METADATA) correctly. PTRACE_SECCOMP_GET_METADATA was only added in 4.16 (26500475ac1b499d8636ff281311d633909f5d20) And it's also breaking seccomp_bpf.c compilation for me: seccomp_bpf.c: In function ‘get_metadata’: seccomp_bpf.c:2878:26: error: storage size of ‘md’ isn’t known struct seccomp_metadata md; ^~ -Tommi

6 years, 8 months

3
2
0 0

[PATCH] btrfs: clean up pending block groups when transaction commit aborts

by David Sterba

The fstests generic/475 stresses transaction aborts and can reveal space accounting or use-after-free bugs regarding block goups. In this case the pending block groups that remain linked to the structures after transaction commit aborts in the middle. The corrupted slabs lead to failures in following tests, eg. generic/476 [ 8172.752887] BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 [ 8172.755799] #PF error: [normal kernel read fault] [ 8172.757571] PGD 661ae067 P4D 661ae067 PUD 3db8e067 PMD 0 [ 8172.759000] Oops: 0000 [#1] PREEMPT SMP [ 8172.760209] CPU: 0 PID: 39 Comm: kswapd0 Tainted: G W 5.0.0-rc2-default #408 [ 8172.762495] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014 [ 8172.765772] RIP: 0010:shrink_page_list+0x2f9/0xe90 [ 8172.770453] RSP: 0018:ffff967f00663b18 EFLAGS: 00010287 [ 8172.771184] RAX: 0000000000000000 RBX: ffff967f00663c20 RCX: 0000000000000000 [ 8172.772850] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8c0620ab20e0 [ 8172.774629] RBP: ffff967f00663dd8 R08: 0000000000000000 R09: 0000000000000000 [ 8172.776094] R10: ffff8c0620ab22f8 R11: ffff8c063f772688 R12: ffff967f00663b78 [ 8172.777533] R13: ffff8c063f625600 R14: ffff8c063f625608 R15: dead000000000200 [ 8172.778886] FS: 0000000000000000(0000) GS:ffff8c063d400000(0000) knlGS:0000000000000000 [ 8172.780545] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8172.781787] CR2: 0000000000000058 CR3: 000000004e962000 CR4: 00000000000006f0 [ 8172.783547] Call Trace: [ 8172.784112] shrink_inactive_list+0x194/0x410 [ 8172.784747] shrink_node_memcg.constprop.85+0x3a5/0x6a0 [ 8172.785472] shrink_node+0x62/0x1e0 [ 8172.786011] balance_pgdat+0x216/0x460 [ 8172.786577] kswapd+0xe3/0x4a0 [ 8172.787085] ? finish_wait+0x80/0x80 [ 8172.787795] ? balance_pgdat+0x460/0x460 [ 8172.788799] kthread+0x116/0x130 [ 8172.789640] ? kthread_create_on_node+0x60/0x60 [ 8172.790323] ret_from_fork+0x24/0x30 [ 8172.794253] CR2: 0000000000000058 or accounting errors at umount time: [ 8159.537251] WARNING: CPU: 2 PID: 19031 at fs/btrfs/extent-tree.c:5987 btrfs_free_block_groups+0x3d5/0x410 [btrfs] [ 8159.543325] CPU: 2 PID: 19031 Comm: umount Tainted: G W 5.0.0-rc2-default #408 [ 8159.545472] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014 [ 8159.548155] RIP: 0010:btrfs_free_block_groups+0x3d5/0x410 [btrfs] [ 8159.554030] RSP: 0018:ffff967f079cbde8 EFLAGS: 00010206 [ 8159.555144] RAX: 0000000001000000 RBX: ffff8c06366cf800 RCX: 0000000000000000 [ 8159.556730] RDX: 0000000000000002 RSI: 0000000000000001 RDI: ffff8c06255ad800 [ 8159.558279] RBP: ffff8c0637ac0000 R08: 0000000000000001 R09: 0000000000000000 [ 8159.559797] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8c0637ac0108 [ 8159.561296] R13: ffff8c0637ac0158 R14: 0000000000000000 R15: dead000000000100 [ 8159.562852] FS: 00007f7f693b9fc0(0000) GS:ffff8c063d800000(0000) knlGS:0000000000000000 [ 8159.564839] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8159.566160] CR2: 00007f7f68fab7b0 CR3: 000000000aec7000 CR4: 00000000000006e0 [ 8159.567898] Call Trace: [ 8159.568597] close_ctree+0x17f/0x350 [btrfs] [ 8159.569628] generic_shutdown_super+0x64/0x100 [ 8159.570808] kill_anon_super+0x14/0x30 [ 8159.571857] btrfs_kill_super+0x12/0xa0 [btrfs] [ 8159.573063] deactivate_locked_super+0x29/0x60 [ 8159.574234] cleanup_mnt+0x3b/0x70 [ 8159.575176] task_work_run+0x98/0xc0 [ 8159.576177] exit_to_usermode_loop+0x83/0x90 [ 8159.577315] do_syscall_64+0x15b/0x180 [ 8159.578339] entry_SYSCALL_64_after_hwframe+0x49/0xbe This fix is based on 2 Josef's patches that used sideefects of btrfs_create_pending_block_groups, this fix introduces the helper that does what we need. CC: stable(a)vger.kernel.org # 4.4+ CC: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: David Sterba <dsterba(a)suse.com> --- fs/btrfs/transaction.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 127fa1535f58..1c23f227525c 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -1895,6 +1895,20 @@ static inline int btrfs_start_delalloc_flush(struct btrfs_fs_info *fs_info) return 0; } +static void btrfs_cleanup_pending_block_groups(struct btrfs_trans_handle *trans) +{ + struct btrfs_fs_info *fs_info = trans->fs_info; + struct btrfs_block_group_cache *block_group; + + while (!list_empty(&trans->new_bgs)) { + block_group = list_first_entry(&trans->new_bgs, + struct btrfs_block_group_cache, + bg_list); + btrfs_delayed_refs_rsv_release(fs_info, 1); + list_del_init(&block_group->bg_list); + } +} + static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) { if (btrfs_test_opt(fs_info, FLUSHONCOMMIT)) @@ -2270,6 +2284,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) btrfs_scrub_continue(fs_info); cleanup_transaction: btrfs_trans_release_metadata(trans); + btrfs_cleanup_pending_block_groups(trans); btrfs_trans_release_chunk_metadata(trans); trans->block_rsv = NULL; btrfs_warn(fs_info, "Skipping commit of aborted transaction."); -- 2.20.1

6 years, 8 months

3
2
0 0

4.14 perf unwind fixes

by Rantala, Tommi T. (Nokia - FI/Espoo)

Hi Greg, Can you please pick these two upstream patches to 4.14? They fix broken perf unwinding for me. commit 3d20c6246690219881786de10d2dda93f616d0ac Author: Martin Vuille < jpmv27(a)aim.com> Date: Sun Feb 11 16:24:20 2018 -0500 perf unwind: Unwind with libdw doesn't take symfs into account commit 1fe627da30331024f453faef04d500079b901107 Author: Milian Wolff < milian.wolff(a)kdab.com> Date: Mon Oct 29 15:16:44 2018 +0100 perf unwind: Take pgoff into account when reporting elf to libdwfl -Tommi

6 years, 8 months

2
1
0 0

[PATCH AUTOSEL 4.20 001/304] drm/bufs: Fix Spectre v1 vulnerability

by Sasha Levin

From: "Gustavo A. R. Silva" <gustavo(a)embeddedor.com> [ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ] idx can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential spectre issue 'dma->buflist' [r] (local cap) Fix this by sanitizing idx before using it to index dma->buflist Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embedd… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_bufs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index 7412acaf3cde..d7d10cabb9bb 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -36,6 +36,8 @@ #include <drm/drmP.h> #include "drm_legacy.h" +#include <linux/nospec.h> + static struct drm_map_list *drm_find_matching_map(struct drm_device *dev, struct drm_local_map *map) { @@ -1417,6 +1419,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void *data, idx, dma->buf_count - 1); return -EINVAL; } + idx = array_index_nospec(idx, dma->buf_count); buf = dma->buflist[idx]; if (buf->file_priv != file_priv) { DRM_ERROR("Process %d freeing buffer not owned\n", -- 2.19.1

6 years, 8 months

6
316
0 0

+ revert-mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: Revert "mm, memory_hotplug: initialize struct pages for the full memory section" has been added to the -mm tree. Its filename is revert-mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/revert-mm-memory_hotplug-initializ… and later at http://ozlabs.org/~akpm/mmotm/broken-out/revert-mm-memory_hotplug-initializ… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Michal Hocko <mhocko(a)suse.com> Subject: Revert "mm, memory_hotplug: initialize struct pages for the full memory section" This reverts 2830bf6f05fb3e05b ("mm, memory_hotplug: initialize struct pages for the full memory section"). The underlying assumption that one sparse section belongs into a single numa node doesn't hold really. Robert Shteynfeld has reported a boot failure. The boot log was not captured but his memory layout is as follows: [ 0.286954] Early memory node ranges [ 0.286955] node 1: [mem 0x0000000000001000-0x0000000000090fff] [ 0.286955] node 1: [mem 0x0000000000100000-0x00000000dbdf8fff] [ 0.286956] node 1: [mem 0x0000000100000000-0x0000001423ffffff] [ 0.286956] node 0: [mem 0x0000001424000000-0x0000002023ffffff] This means that node0 starts in the middle of a memory section which is also in node1. memmap_init_zone tries to initialize padding of a section even when it is outside of the given pfn range because there are code paths (e.g. memory hotplug) which assume that the full worth of memory section is always initialized. In this particular case, though, such a range is already intialized and most likely already managed by the page allocator. Scribbling over those pages corrupts the internal state and likely blows up when any of those pages gets used. Link: http://lkml.kernel.org/r/20190125181549.GE20411@dhcp22.suse.cz Fixes: 2830bf6f05fb ("mm, memory_hotplug: initialize struct pages for the full memory section") Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Robert Shteynfeld <robert.shteynfeld(a)gmail.com> Cc: Mikhail Zaslonko <zaslonko(a)linux.ibm.com> Cc: Gerald Schaefer <gerald.schaefer(a)de.ibm.com> Cc: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Alexander Duyck <alexander.h.duyck(a)linux.intel.com> Cc: Pasha Tatashin <Pavel.Tatashin(a)microsoft.com> Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 12 ------------ 1 file changed, 12 deletions(-) --- a/mm/page_alloc.c~revert-mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section +++ a/mm/page_alloc.c @@ -5701,18 +5701,6 @@ void __meminit memmap_init_zone(unsigned cond_resched(); } } -#ifdef CONFIG_SPARSEMEM - /* - * If the zone does not span the rest of the section then - * we should at least initialize those pages. Otherwise we - * could blow up on a poisoned page in some paths which depend - * on full sections being initialized (e.g. memory hotplug). - */ - while (end_pfn % PAGES_PER_SECTION) { - __init_single_page(pfn_to_page(end_pfn), end_pfn, zone, nid); - end_pfn++; - } -#endif } #ifdef CONFIG_ZONE_DEVICE _ Patches currently in -mm which might be from mhocko(a)suse.com are mm-memory_hotplug-is_mem_section_removable-do-not-pass-the-end-of-a-zone.patch revert-mm-memory_hotplug-initialize-struct-pages-for-the-full-memory-section.patch mm-oom-marks-all-killed-tasks-as-oom-victims.patch memcg-do-not-report-racy-no-eligible-oom-tasks.patch

6 years, 8 months

1
0
0 0

[RFC][PATCH] Revert "ARM: dts: bcm2837: Fix polarity of wifi reset GPIOs"

by Ioan-Adrian Ratiu

This reverts commit bea8a160c621d19f7f78b13e14e03f4b8e44cd4b. Contrary to what the commit message says, on my rpi 3 b v1.2 changing the polarity causes the exact behaviour this commit intends to fix, as described at the referenced link below (wlan0 disapears). With reset-gpios = ... GPIO_ACTIVE_HIGH, brcmfmac errors in dmesg: [ 7.977512] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110 [ 7.977623] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 7.978007] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 7.978377] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 7.978724] brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation [ 7.978734] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 [ 7.978747] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-110) [ 7.982817] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110 [ 7.982880] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 7.983255] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame The only solution I currently have is to revert and everything works as expected and as before changing the polarity. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911443 Signed-off-by: Ioan-Adrian Ratiu <adi(a)adirat.com> --- arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts | 2 +- arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts index 93762244be7f..4adb85e66be3 100644 --- a/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts @@ -31,7 +31,7 @@ wifi_pwrseq: wifi-pwrseq { compatible = "mmc-pwrseq-simple"; - reset-gpios = <&expgpio 1 GPIO_ACTIVE_LOW>; + reset-gpios = <&expgpio 1 GPIO_ACTIVE_HIGH>; }; }; diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts index 89e6fd547c75..c318bcbc6ba7 100644 --- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts @@ -26,7 +26,7 @@ wifi_pwrseq: wifi-pwrseq { compatible = "mmc-pwrseq-simple"; - reset-gpios = <&expgpio 1 GPIO_ACTIVE_LOW>; + reset-gpios = <&expgpio 1 GPIO_ACTIVE_HIGH>; }; }; -- 2.20.1

6 years, 8 months

3
5
0 0

+ mm-migrate-make-buffer_migrate_page_norefs-actually-succeed.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: migrate: make buffer_migrate_page_norefs() actually succeed has been added to the -mm tree. Its filename is mm-migrate-make-buffer_migrate_page_norefs-actually-succeed.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-make-buffer_migrate_pag… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-make-buffer_migrate_pag… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Jan Kara <jack(a)suse.cz> Subject: mm: migrate: make buffer_migrate_page_norefs() actually succeed Currently, buffer_migrate_page_norefs() was constantly failing because buffer_migrate_lock_buffers() grabbed reference on each buffer. In fact, there's no reason for buffer_migrate_lock_buffers() to grab any buffer references as the page is locked during all our operation and thus nobody can reclaim buffers from the page. So remove grabbing of buffer references which also makes buffer_migrate_page_norefs() succeed. Link: http://lkml.kernel.org/r/20190116131217.7226-1-jack@suse.cz Fixes: 89cb0888ca14 "mm: migrate: provide buffer_migrate_page_norefs()" Signed-off-by: Jan Kara <jack(a)suse.cz> Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com> Cc: Pavel Machek <pavel(a)ucw.cz> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Zi Yan <zi.yan(a)cs.rutgers.edu> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/migrate.c | 5 ----- 1 file changed, 5 deletions(-) --- a/mm/migrate.c~mm-migrate-make-buffer_migrate_page_norefs-actually-succeed +++ a/mm/migrate.c @@ -709,7 +709,6 @@ static bool buffer_migrate_lock_buffers( /* Simple case, sync compaction */ if (mode != MIGRATE_ASYNC) { do { - get_bh(bh); lock_buffer(bh); bh = bh->b_this_page; @@ -720,18 +719,15 @@ static bool buffer_migrate_lock_buffers( /* async case, we cannot block on lock_buffer so use trylock_buffer */ do { - get_bh(bh); if (!trylock_buffer(bh)) { /* * We failed to lock the buffer and cannot stall in * async migration. Release the taken locks */ struct buffer_head *failed_bh = bh; - put_bh(failed_bh); bh = head; while (bh != failed_bh) { unlock_buffer(bh); - put_bh(bh); bh = bh->b_this_page; } return false; @@ -818,7 +814,6 @@ unlock_buffers: bh = head; do { unlock_buffer(bh); - put_bh(bh); bh = bh->b_this_page; } while (bh != head); _ Patches currently in -mm which might be from jack(a)suse.cz are mm-migrate-make-buffer_migrate_page_norefs-actually-succeed.patch

6 years, 8 months

1
0
0 0

+ mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: migrate: don't rely on PageMovable() of newpage after unlocking it has been added to the -mm tree. Its filename is mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-dont-rely-on-pagemovabl… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-dont-rely-on-pagemovabl… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: David Hildenbrand <david(a)redhat.com> Subject: mm: migrate: don't rely on PageMovable() of newpage after unlocking it While debugging some crashes related to virtio-balloon deflation that happened under the old balloon migration code, I stumbled over a race that still exists today. What we experienced: drivers/virtio/virtio_balloon.c:release_pages_balloon(): - WARNING: CPU: 13 PID: 6586 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0 - list_del corruption. prev->next should be ffffe253961090a0, but was dead000000000100 Turns out after having added the page to a local list when dequeuing, the page would suddenly be moved to an LRU list before we would free it via the local list, corrupting both lists. So a page we own and that is !LRU was moved to an LRU list. In __unmap_and_move(), we lock the old and newpage and perform the migration. In case of vitio-balloon, the new page will become movable, the old page will no longer be movable. However, after unlocking newpage, there is nothing stopping the newpage from getting dequeued and freed by virtio-balloon. This will result in the newpage 1. No longer having PageMovable() 2. Getting moved to the local list before finally freeing it (using page->lru) Back in the migration thread in __unmap_and_move(), we would after unlocking the newpage suddenly no longer have PageMovable(newpage) and will therefore call putback_lru_page(newpage), modifying page->lru although that list is still in use by virtio-balloon. To summarize, we have a race between migrating the newpage and checking for PageMovable(newpage). Instead of checking PageMovable(newpage), we can simply rely on is_lru of the original page. Looks like this was introduced by d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management"), which was backported up to 3.12. Old compaction code used PageBalloon() via -_is_movable_balloon_page() instead of PageMovable(), however with the same semantics. Link: http://lkml.kernel.org/r/20190128160403.16657-1-david@redhat.com Fixes: d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management") Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: Vratislav Bendel <vbendel(a)redhat.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Rafael Aquini <aquini(a)redhat.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Jan Kara <jack(a)suse.cz> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Dominik Brodowski <linux(a)dominikbrodowski.net> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Konstantin Khlebnikov <k.khlebnikov(a)samsung.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: <stable(a)vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/migrate.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/mm/migrate.c~mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it +++ a/mm/migrate.c @@ -1135,10 +1135,12 @@ out: * If migration is successful, decrease refcount of the newpage * which will not free the page because new page owner increased * refcounter. As well, if it is LRU page, add the page to LRU - * list in here. + * list in here. Don't rely on PageMovable(newpage), as that could + * already have changed after unlocking newpage (e.g. + * virtio-balloon deflation). */ if (rc == MIGRATEPAGE_SUCCESS) { - if (unlikely(__PageMovable(newpage))) + if (unlikely(!is_lru)) put_page(newpage); else putback_lru_page(newpage); _ Patches currently in -mm which might be from david(a)redhat.com are mm-balloon-update-comment-about-isolation-migration-compaction.patch mm-convert-pg_balloon-to-pg_offline.patch kexec-export-pg_offline-to-vmcoreinfo.patch xen-balloon-mark-inflated-pages-pg_offline.patch hv_balloon-mark-inflated-pages-pg_offline.patch vmw_balloon-mark-inflated-pages-pg_offline.patch vmw_balloon-mark-inflated-pages-pg_offline-v2.patch pm-hibernate-use-pfn_to_online_page.patch pm-hibernate-exclude-all-pageoffline-pages.patch pm-hibernate-exclude-all-pageoffline-pages-v2.patch mm-migrate-dont-rely-on-pagemovable-of-newpage-after-unlocking-it.patch

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] dm: fix redundant IO accounting for bios that need splitting" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a1e1cb72d96491277ede8d257ce6b48a381dd336 Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer(a)redhat.com> Date: Thu, 17 Jan 2019 10:48:01 -0500 Subject: [PATCH] dm: fix redundant IO accounting for bios that need splitting The risk of redundant IO accounting was not taken into consideration when commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") introduced IO splitting in terms of recursion via generic_make_request(). Fix this by subtracting the split bio's payload from the IO stats that were already accounted for by start_io_acct() upon dm_make_request() entry. This repeat oscillation of the IO accounting, up then down, isn't ideal but refactoring DM core's IO splitting to pre-split bios _before_ they are accounted turned out to be an excessive amount of change that will need a full development cycle to refine and verify. Before this fix: /dev/mapper/stripe_dev is a 4-way stripe using a 32k chunksize, so bios are split on 32k boundaries. # fio --name=16M --filename=/dev/mapper/stripe_dev --rw=write --bs=64k --size=16M \ --iodepth=1 --ioengine=libaio --direct=1 --refill_buffers with debugging added: [103898.310264] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=0 len=128 [103898.318704] device-mapper: core: __split_and_process_bio: recursing for following split bio: [103898.329136] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=64 len=64 ... 16M written yet 136M (278528 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 278528 After this fix: 16M written and 16M (32768 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 32768 Fixes: 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") Cc: stable(a)vger.kernel.org # 4.16+ Reported-by: Bryan Gurney <bgurney(a)redhat.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm.c b/drivers/md/dm.c index fcb97b0a5743..fbadda68e23b 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1584,6 +1584,9 @@ static void init_clone_info(struct clone_info *ci, struct mapped_device *md, ci->sector = bio->bi_iter.bi_sector; } +#define __dm_part_stat_sub(part, field, subnd) \ + (part_stat_get(part, field) -= (subnd)) + /* * Entry point to split a bio into clones and submit them to the targets. */ @@ -1638,6 +1641,19 @@ static blk_qc_t __split_and_process_bio(struct mapped_device *md, struct bio *b = bio_split(bio, bio_sectors(bio) - ci.sector_count, GFP_NOIO, &md->queue->bio_split); ci.io->orig_bio = b; + + /* + * Adjust IO stats for each split, otherwise upon queue + * reentry there will be redundant IO accounting. + * NOTE: this is a stop-gap fix, a proper fix involves + * significant refactoring of DM core's bio splitting + * (by eliminating DM's splitting and just using bio_split) + */ + part_stat_lock(); + __dm_part_stat_sub(&dm_disk(md)->part0, + sectors[op_stat_group(bio_op(bio))], ci.sector_count); + part_stat_unlock(); + bio_chain(b, bio); ret = generic_make_request(bio); break;

6 years, 8 months

3
3
0 0

Re: [PATCH v2] drm/meson: Fix atomic mode switching regression

by Neil Armstrong

Hi Stable kernel team, On 14/01/2019 16:31, Neil Armstrong wrote: > Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for > example) the display gets blurry, looking like an invalid framebuffer width. > > This commit fixed atomic crtc modesetting in a totally wrong way and > introduced a local unnecessary ->enabled crtc state. > > This commit reverts the crctc _begin() and _enable() changes and simply > adds drm_atomic_helper_commit_tail_rpm as helper. > > Reported-by: Tony McKahan <tonymckahan(a)gmail.com> > Suggested-by: Daniel Vetter <daniel(a)ffwll.ch> > Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support") > Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> This fix has landed in linus master with id ce0210c12433031aba3bbacd75f4c02ab77f2004 could it be applied to 4.19 and 4.20 stable trees ? Thanks, Neil > --- > drivers/gpu/drm/meson/meson_crtc.c | 23 ++--------------------- > drivers/gpu/drm/meson/meson_drv.c | 6 ++++++ > 2 files changed, 8 insertions(+), 21 deletions(-) > > Changes since v1: > - drop the unecessary local ->enabled logic > - use drm_atomic_helper_commit_tail_rpm as atomic_commit_tail helper > > diff --git a/drivers/gpu/drm/meson/meson_crtc.c b/drivers/gpu/drm/meson/meson_crtc.c > index 75d97f1b2e8f..4f5c67f70c4d 100644 > --- a/drivers/gpu/drm/meson/meson_crtc.c > +++ b/drivers/gpu/drm/meson/meson_crtc.c > @@ -46,7 +46,6 @@ struct meson_crtc { > struct drm_crtc base; > struct drm_pending_vblank_event *event; > struct meson_drm *priv; > - bool enabled; > }; > #define to_meson_crtc(x) container_of(x, struct meson_crtc, base) > > @@ -82,7 +81,8 @@ static const struct drm_crtc_funcs meson_crtc_funcs = { > > }; > > -static void meson_crtc_enable(struct drm_crtc *crtc) > +static void meson_crtc_atomic_enable(struct drm_crtc *crtc, > + struct drm_crtc_state *old_state) > { > struct meson_crtc *meson_crtc = to_meson_crtc(crtc); > struct drm_crtc_state *crtc_state = crtc->state; > @@ -108,20 +108,6 @@ static void meson_crtc_enable(struct drm_crtc *crtc) > > drm_crtc_vblank_on(crtc); > > - meson_crtc->enabled = true; > -} > - > -static void meson_crtc_atomic_enable(struct drm_crtc *crtc, > - struct drm_crtc_state *old_state) > -{ > - struct meson_crtc *meson_crtc = to_meson_crtc(crtc); > - struct meson_drm *priv = meson_crtc->priv; > - > - DRM_DEBUG_DRIVER("\n"); > - > - if (!meson_crtc->enabled) > - meson_crtc_enable(crtc); > - > priv->viu.osd1_enabled = true; > } > > @@ -153,8 +139,6 @@ static void meson_crtc_atomic_disable(struct drm_crtc *crtc, > > crtc->state->event = NULL; > } > - > - meson_crtc->enabled = false; > } > > static void meson_crtc_atomic_begin(struct drm_crtc *crtc, > @@ -163,9 +147,6 @@ static void meson_crtc_atomic_begin(struct drm_crtc *crtc, > struct meson_crtc *meson_crtc = to_meson_crtc(crtc); > unsigned long flags; > > - if (crtc->state->enable && !meson_crtc->enabled) > - meson_crtc_enable(crtc); > - > if (crtc->state->event) { > WARN_ON(drm_crtc_vblank_get(crtc) != 0); > > diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c > index 3ee4d4a4ecba..a74d861ddceb 100644 > --- a/drivers/gpu/drm/meson/meson_drv.c > +++ b/drivers/gpu/drm/meson/meson_drv.c > @@ -75,6 +75,11 @@ static const struct drm_mode_config_funcs meson_mode_config_funcs = { > .fb_create = drm_gem_fb_create, > }; > > + > +static const struct drm_mode_config_helper_funcs meson_mode_config_helpers = { > + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm, > +}; > + > static irqreturn_t meson_irq(int irq, void *arg) > { > struct drm_device *dev = arg; > @@ -266,6 +271,7 @@ static int meson_drv_bind_master(struct device *dev, bool has_components) > drm->mode_config.max_width = 3840; > drm->mode_config.max_height = 2160; > drm->mode_config.funcs = &meson_mode_config_funcs; > + drm->mode_config.helper_private = &meson_mode_config_helpers; > > /* Hardware Initialization */ > >

6 years, 8 months

2
1
0 0

[PATCH AUTOSEL 3.18 01/61] staging: iio: adc: ad7280a: handle error from __ad7280_read32()

by Sasha Levin

From: Slawomir Stepien <sst(a)poczta.fm> [ Upstream commit 0559ef7fde67bc6c83c6eb6329dbd6649528263e ] Inside __ad7280_read32(), the spi_sync_transfer() can fail with negative error code. This change will ensure that this error is being passed up in the call stack, so it can be handled. Signed-off-by: Slawomir Stepien <sst(a)poczta.fm> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/iio/adc/ad7280a.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/staging/iio/adc/ad7280a.c b/drivers/staging/iio/adc/ad7280a.c index d215edf66af2..0ad4af5d0ae4 100644 --- a/drivers/staging/iio/adc/ad7280a.c +++ b/drivers/staging/iio/adc/ad7280a.c @@ -250,7 +250,9 @@ static int ad7280_read(struct ad7280_state *st, unsigned devaddr, if (ret) return ret; - __ad7280_read32(st, &tmp); + ret = __ad7280_read32(st, &tmp); + if (ret) + return ret; if (ad7280_check_crc(st, tmp)) return -EIO; @@ -288,7 +290,9 @@ static int ad7280_read_channel(struct ad7280_state *st, unsigned devaddr, ad7280_delay(st); - __ad7280_read32(st, &tmp); + ret = __ad7280_read32(st, &tmp); + if (ret) + return ret; if (ad7280_check_crc(st, tmp)) return -EIO; @@ -321,7 +325,9 @@ static int ad7280_read_all_channels(struct ad7280_state *st, unsigned cnt, ad7280_delay(st); for (i = 0; i < cnt; i++) { - __ad7280_read32(st, &tmp); + ret = __ad7280_read32(st, &tmp); + if (ret) + return ret; if (ad7280_check_crc(st, tmp)) return -EIO; @@ -364,7 +370,10 @@ static int ad7280_chain_setup(struct ad7280_state *st) return ret; for (n = 0; n <= AD7280A_MAX_CHAIN; n++) { - __ad7280_read32(st, &val); + ret = __ad7280_read32(st, &val); + if (ret) + return ret; + if (val == 0) return n - 1; -- 2.19.1

6 years, 8 months

1
60
0 0

[PATCH AUTOSEL 4.4 01/80] drm/bufs: Fix Spectre v1 vulnerability

by Sasha Levin

From: "Gustavo A. R. Silva" <gustavo(a)embeddedor.com> [ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ] idx can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential spectre issue 'dma->buflist' [r] (local cap) Fix this by sanitizing idx before using it to index dma->buflist Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embedd… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_bufs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index f1a204d253cc..ac22b8d86249 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -36,6 +36,8 @@ #include <drm/drmP.h> #include "drm_legacy.h" +#include <linux/nospec.h> + static struct drm_map_list *drm_find_matching_map(struct drm_device *dev, struct drm_local_map *map) { @@ -1332,6 +1334,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void *data, idx, dma->buf_count - 1); return -EINVAL; } + idx = array_index_nospec(idx, dma->buf_count); buf = dma->buflist[idx]; if (buf->file_priv != file_priv) { DRM_ERROR("Process %d freeing buffer not owned\n", -- 2.19.1

6 years, 8 months

1
79
0 0

[PATCH AUTOSEL 4.9 001/107] drm/bufs: Fix Spectre v1 vulnerability

by Sasha Levin

From: "Gustavo A. R. Silva" <gustavo(a)embeddedor.com> [ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ] idx can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential spectre issue 'dma->buflist' [r] (local cap) Fix this by sanitizing idx before using it to index dma->buflist Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embedd… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_bufs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index adb1dd7fde5f..9ccd7d702cd3 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -36,6 +36,8 @@ #include <drm/drmP.h> #include "drm_legacy.h" +#include <linux/nospec.h> + static struct drm_map_list *drm_find_matching_map(struct drm_device *dev, struct drm_local_map *map) { @@ -1413,6 +1415,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void *data, idx, dma->buf_count - 1); return -EINVAL; } + idx = array_index_nospec(idx, dma->buf_count); buf = dma->buflist[idx]; if (buf->file_priv != file_priv) { DRM_ERROR("Process %d freeing buffer not owned\n", -- 2.19.1

6 years, 8 months

1
106
0 0

Re: [PATCH 4/4] can: flexcan: fix NULL pointer exception during bringup

by Uwe Kleine-König

Hello Sasha, On Wed, Jan 23, 2019 at 10:57:44PM +0000, Sasha Levin wrote: > [This is an automated email] Not sure if I only state the obvious that was just missed by your automation. > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: cbffaf7aa09e can: flexcan: Always use last mailbox for TX. > > The bot has tested the following trees: v4.20.3, v4.19.16. > > v4.20.3: Failed to apply! Possible dependencies: > 0517961ccdf1 ("can: flexcan: Add provision for variable payload size") > 22233f7bf2c9 ("can: flexcan: FLEXCAN_IFLAG_MB: add () around macro argument") > 5156c7b11f35 ("can: flexcan: move rx_offload_add() from flexcan_probe() to flexcan_open()") > 7ad0f53a394b ("can: flexcan: flexcan_chip_start(): enable loopback mode in flexcan") > de3578c198c6 ("can: flexcan: add self wakeup support") > > v4.19.16: Failed to apply! Possible dependencies: > 0517961ccdf1 ("can: flexcan: Add provision for variable payload size") > 22233f7bf2c9 ("can: flexcan: FLEXCAN_IFLAG_MB: add () around macro argument") > 5156c7b11f35 ("can: flexcan: move rx_offload_add() from flexcan_probe() to flexcan_open()") > 7ad0f53a394b ("can: flexcan: flexcan_chip_start(): enable loopback mode in flexcan") > de3578c198c6 ("can: flexcan: add self wakeup support") > > > How should we proceed with this patch? When I posted the commit I also posted one that fits on top of v4.19.x. I would expect that the same also fits on v4.20.x. If not, tell me. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |

6 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] can: flexcan: fix NULL pointer exception during bringup" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a55234dabe1f72cf22f9197980751d37e38ba020 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig(a)pengutronix.de> Date: Fri, 11 Jan 2019 12:20:41 +0100 Subject: [PATCH] can: flexcan: fix NULL pointer exception during bringup MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX") introduced a loop letting i run up to (including) ARRAY_SIZE(regs->mb) and in the body accessed regs->mb[i] which is an out-of-bounds array access that then resulted in an access to an reserved register area. Later this was changed by commit 0517961ccdf1 ("can: flexcan: Add provision for variable payload size") to iterate a bit differently but still runs one iteration too much resulting to call flexcan_get_mb(priv, priv->mb_count) which results in a WARN_ON and then a NULL pointer exception. This only affects devices compatible with "fsl,p1010-flexcan", "fsl,imx53-flexcan", "fsl,imx35-flexcan", "fsl,imx25-flexcan", "fsl,imx28-flexcan", so newer i.MX SoCs are not affected. Fixes: cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX") Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Cc: linux-stable <stable(a)vger.kernel.org> # >= 4.20 Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index 5f097648d12d..1c66fb2ad76b 100644 --- a/drivers/net/can/flexcan.c +++ b/drivers/net/can/flexcan.c @@ -1106,7 +1106,7 @@ static int flexcan_chip_start(struct net_device *dev) } } else { /* clear and invalidate unused mailboxes first */ - for (i = FLEXCAN_TX_MB_RESERVED_OFF_FIFO; i <= priv->mb_count; i++) { + for (i = FLEXCAN_TX_MB_RESERVED_OFF_FIFO; i < priv->mb_count; i++) { mb = flexcan_get_mb(priv, i); priv->write(FLEXCAN_MB_CODE_RX_INACTIVE, &mb->can_ctrl);

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] can: flexcan: fix NULL pointer exception during bringup" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a55234dabe1f72cf22f9197980751d37e38ba020 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig(a)pengutronix.de> Date: Fri, 11 Jan 2019 12:20:41 +0100 Subject: [PATCH] can: flexcan: fix NULL pointer exception during bringup MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX") introduced a loop letting i run up to (including) ARRAY_SIZE(regs->mb) and in the body accessed regs->mb[i] which is an out-of-bounds array access that then resulted in an access to an reserved register area. Later this was changed by commit 0517961ccdf1 ("can: flexcan: Add provision for variable payload size") to iterate a bit differently but still runs one iteration too much resulting to call flexcan_get_mb(priv, priv->mb_count) which results in a WARN_ON and then a NULL pointer exception. This only affects devices compatible with "fsl,p1010-flexcan", "fsl,imx53-flexcan", "fsl,imx35-flexcan", "fsl,imx25-flexcan", "fsl,imx28-flexcan", so newer i.MX SoCs are not affected. Fixes: cbffaf7aa09e ("can: flexcan: Always use last mailbox for TX") Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Cc: linux-stable <stable(a)vger.kernel.org> # >= 4.20 Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index 5f097648d12d..1c66fb2ad76b 100644 --- a/drivers/net/can/flexcan.c +++ b/drivers/net/can/flexcan.c @@ -1106,7 +1106,7 @@ static int flexcan_chip_start(struct net_device *dev) } } else { /* clear and invalidate unused mailboxes first */ - for (i = FLEXCAN_TX_MB_RESERVED_OFF_FIFO; i <= priv->mb_count; i++) { + for (i = FLEXCAN_TX_MB_RESERVED_OFF_FIFO; i < priv->mb_count; i++) { mb = flexcan_get_mb(priv, i); priv->write(FLEXCAN_MB_CODE_RX_INACTIVE, &mb->can_ctrl);

6 years, 8 months

1
0
0 0

[PATCH AUTOSEL 4.14 001/170] drm/bufs: Fix Spectre v1 vulnerability

by Sasha Levin

From: "Gustavo A. R. Silva" <gustavo(a)embeddedor.com> [ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ] idx can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential spectre issue 'dma->buflist' [r] (local cap) Fix this by sanitizing idx before using it to index dma->buflist Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embedd… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_bufs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index 1ee84dd802d4..0f05b8d8fefa 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -36,6 +36,8 @@ #include <drm/drmP.h> #include "drm_legacy.h" +#include <linux/nospec.h> + static struct drm_map_list *drm_find_matching_map(struct drm_device *dev, struct drm_local_map *map) { @@ -1417,6 +1419,7 @@ int drm_legacy_freebufs(struct drm_device *dev, void *data, idx, dma->buf_count - 1); return -EINVAL; } + idx = array_index_nospec(idx, dma->buf_count); buf = dma->buflist[idx]; if (buf->file_priv != file_priv) { DRM_ERROR("Process %d freeing buffer not owned\n", -- 2.19.1

6 years, 8 months

2
170
0 0

FAILED: patch "[PATCH] irqchip/gic-v3-its: Align PCI Multi-MSI allocation on their" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8208d1708b88b412ca97f50a6d951242c88cbbac Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Fri, 18 Jan 2019 14:08:59 +0000 Subject: [PATCH] irqchip/gic-v3-its: Align PCI Multi-MSI allocation on their size The way we allocate events works fine in most cases, except when multiple PCI devices share an ITS-visible DevID, and that one of them is trying to use MultiMSI allocation. In that case, our allocation is not guaranteed to be zero-based anymore, and we have to make sure we allocate it on a boundary that is compatible with the PCI Multi-MSI constraints. Fix this by allocating the full region upfront instead of iterating over the number of MSIs. MSI-X are always allocated one by one, so this shouldn't change anything on that front. Fixes: b48ac83d6bbc2 ("irqchip: GICv3: ITS: MSI support") Cc: stable(a)vger.kernel.org Reported-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index db20e992a40f..7f2a45445b00 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -2399,13 +2399,14 @@ static void its_free_device(struct its_device *its_dev) kfree(its_dev); } -static int its_alloc_device_irq(struct its_device *dev, irq_hw_number_t *hwirq) +static int its_alloc_device_irq(struct its_device *dev, int nvecs, irq_hw_number_t *hwirq) { int idx; - idx = find_first_zero_bit(dev->event_map.lpi_map, - dev->event_map.nr_lpis); - if (idx == dev->event_map.nr_lpis) + idx = bitmap_find_free_region(dev->event_map.lpi_map, + dev->event_map.nr_lpis, + get_count_order(nvecs)); + if (idx < 0) return -ENOSPC; *hwirq = dev->event_map.lpi_base + idx; @@ -2501,21 +2502,21 @@ static int its_irq_domain_alloc(struct irq_domain *domain, unsigned int virq, int err; int i; - for (i = 0; i < nr_irqs; i++) { - err = its_alloc_device_irq(its_dev, &hwirq); - if (err) - return err; + err = its_alloc_device_irq(its_dev, nr_irqs, &hwirq); + if (err) + return err; - err = its_irq_gic_domain_alloc(domain, virq + i, hwirq); + for (i = 0; i < nr_irqs; i++) { + err = its_irq_gic_domain_alloc(domain, virq + i, hwirq + i); if (err) return err; irq_domain_set_hwirq_and_chip(domain, virq + i, - hwirq, &its_irq_chip, its_dev); + hwirq + i, &its_irq_chip, its_dev); irqd_set_single_target(irq_desc_get_irq_data(irq_to_desc(virq + i))); pr_debug("ID:%d pID:%d vID:%d\n", - (int)(hwirq - its_dev->event_map.lpi_base), - (int) hwirq, virq + i); + (int)(hwirq + i - its_dev->event_map.lpi_base), + (int)(hwirq + i), virq + i); } return 0;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] irqchip/gic-v3-its: Align PCI Multi-MSI allocation on their" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8208d1708b88b412ca97f50a6d951242c88cbbac Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Fri, 18 Jan 2019 14:08:59 +0000 Subject: [PATCH] irqchip/gic-v3-its: Align PCI Multi-MSI allocation on their size The way we allocate events works fine in most cases, except when multiple PCI devices share an ITS-visible DevID, and that one of them is trying to use MultiMSI allocation. In that case, our allocation is not guaranteed to be zero-based anymore, and we have to make sure we allocate it on a boundary that is compatible with the PCI Multi-MSI constraints. Fix this by allocating the full region upfront instead of iterating over the number of MSIs. MSI-X are always allocated one by one, so this shouldn't change anything on that front. Fixes: b48ac83d6bbc2 ("irqchip: GICv3: ITS: MSI support") Cc: stable(a)vger.kernel.org Reported-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index db20e992a40f..7f2a45445b00 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -2399,13 +2399,14 @@ static void its_free_device(struct its_device *its_dev) kfree(its_dev); } -static int its_alloc_device_irq(struct its_device *dev, irq_hw_number_t *hwirq) +static int its_alloc_device_irq(struct its_device *dev, int nvecs, irq_hw_number_t *hwirq) { int idx; - idx = find_first_zero_bit(dev->event_map.lpi_map, - dev->event_map.nr_lpis); - if (idx == dev->event_map.nr_lpis) + idx = bitmap_find_free_region(dev->event_map.lpi_map, + dev->event_map.nr_lpis, + get_count_order(nvecs)); + if (idx < 0) return -ENOSPC; *hwirq = dev->event_map.lpi_base + idx; @@ -2501,21 +2502,21 @@ static int its_irq_domain_alloc(struct irq_domain *domain, unsigned int virq, int err; int i; - for (i = 0; i < nr_irqs; i++) { - err = its_alloc_device_irq(its_dev, &hwirq); - if (err) - return err; + err = its_alloc_device_irq(its_dev, nr_irqs, &hwirq); + if (err) + return err; - err = its_irq_gic_domain_alloc(domain, virq + i, hwirq); + for (i = 0; i < nr_irqs; i++) { + err = its_irq_gic_domain_alloc(domain, virq + i, hwirq + i); if (err) return err; irq_domain_set_hwirq_and_chip(domain, virq + i, - hwirq, &its_irq_chip, its_dev); + hwirq + i, &its_irq_chip, its_dev); irqd_set_single_target(irq_desc_get_irq_data(irq_to_desc(virq + i))); pr_debug("ID:%d pID:%d vID:%d\n", - (int)(hwirq - its_dev->event_map.lpi_base), - (int) hwirq, virq + i); + (int)(hwirq + i - its_dev->event_map.lpi_base), + (int)(hwirq + i), virq + i); } return 0;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 60f1bf29c0b2519989927cae640cd1f50f59dc7f Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Fri, 11 Jan 2019 15:18:22 +0100 Subject: [PATCH] s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU When calling smp_call_ipl_cpu() from the IPL CPU, we will try to read from pcpu_devices->lowcore. However, due to prefixing, that will result in reading from absolute address 0 on that CPU. We have to go via the actual lowcore instead. This means that right now, we will read lc->nodat_stack == 0 and therfore work on a very wrong stack. This BUG essentially broke rebooting under QEMU TCG (which will report a low address protection exception). And checking under KVM, it is also broken under KVM. With 1 VCPU it can be easily triggered. :/# echo 1 > /proc/sys/kernel/sysrq :/# echo b > /proc/sysrq-trigger [ 28.476745] sysrq: SysRq : Resetting [ 28.476793] Kernel stack overflow. [ 28.476817] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13 [ 28.476820] Hardware name: IBM 2964 NE1 716 (KVM/Linux) [ 28.476826] Krnl PSW : 0400c00180000000 0000000000115c0c (pcpu_delegate+0x12c/0x140) [ 28.476861] R:0 T:1 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 [ 28.476863] Krnl GPRS: ffffffffffffffff 0000000000000000 000000000010dff8 0000000000000000 [ 28.476864] 0000000000000000 0000000000000000 0000000000ab7090 000003e0006efbf0 [ 28.476864] 000000000010dff8 0000000000000000 0000000000000000 0000000000000000 [ 28.476865] 000000007fffc000 0000000000730408 000003e0006efc58 0000000000000000 [ 28.476887] Krnl Code: 0000000000115bfe: 4170f000 la %r7,0(%r15) [ 28.476887] 0000000000115c02: 41f0a000 la %r15,0(%r10) [ 28.476887] #0000000000115c06: e370f0980024 stg %r7,152(%r15) [ 28.476887] >0000000000115c0c: c0e5fffff86e brasl %r14,114ce8 [ 28.476887] 0000000000115c12: 41f07000 la %r15,0(%r7) [ 28.476887] 0000000000115c16: a7f4ffa8 brc 15,115b66 [ 28.476887] 0000000000115c1a: 0707 bcr 0,%r7 [ 28.476887] 0000000000115c1c: 0707 bcr 0,%r7 [ 28.476901] Call Trace: [ 28.476902] Last Breaking-Event-Address: [ 28.476920] [<0000000000a01c4a>] arch_call_rest_init+0x22/0x80 [ 28.476927] Kernel panic - not syncing: Corrupt kernel stack, can't continue. [ 28.476930] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13 [ 28.476932] Hardware name: IBM 2964 NE1 716 (KVM/Linux) [ 28.476932] Call Trace: Fixes: 2f859d0dad81 ("s390/smp: reduce size of struct pcpu") Cc: stable(a)vger.kernel.org # 4.0+ Reported-by: Cornelia Huck <cohuck(a)redhat.com> Signed-off-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c index 307a1c86ea21..b198ece2aad6 100644 --- a/arch/s390/kernel/smp.c +++ b/arch/s390/kernel/smp.c @@ -381,8 +381,13 @@ void smp_call_online_cpu(void (*func)(void *), void *data) */ void smp_call_ipl_cpu(void (*func)(void *), void *data) { + struct lowcore *lc = pcpu_devices->lowcore; + + if (pcpu_devices[0].address == stap()) + lc = &S390_lowcore; + pcpu_delegate(&pcpu_devices[0], func, data, - pcpu_devices->lowcore->nodat_stack); + lc->nodat_stack); } int smp_find_processor_id(u16 address)

6 years, 8 months

2
1
0 0

[PATCH] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS which misprograms the hardware badly when encountering a suitably high resolution display. The programmed pipe timings are somewhat bonkers and the DPLL is totally misprogrammed (P divider == 0). That will result in atomic commit timeouts as apparently the pipe is sufficiently stuck to not signal vblank interrupts. IIRC something like this was also observed on some other SNB machine years ago (might have been a Dell XPS 8300) but a BIOS update cured it. Sadly looks like this was never fixed for the ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still broken. The quickest way to deal with this seems to be to shut down the pipe+ports+DPLL. Unfortunately doing this during the normal sanitization phase isn't quite soon enough as we already spew several WARNs about the bogus hardware state. But it's better than hanging the boot for a few dozen seconds. Since this is limited to a few old machines it doesn't seem entirely worthwile to try and rework the readout+sanitization code to handle it more gracefully. Cc: stable(a)vger.kernel.org # v4.20+ Cc: Daniel Kamil Kozar <dkk089(a)gmail.com> Reported-by: Daniel Kamil Kozar <dkk089(a)gmail.com> Tested-by: Daniel Kamil Kozar <dkk089(a)gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245 Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/intel_display.c | 51 ++++++++++++++++++++++++---- 1 file changed, 45 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 696e6f5680df..ea2e09d36b4d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15435,16 +15435,46 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc, } } +static bool has_bogus_dpll_config(struct intel_crtc_state *crtc_state) +{ + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev); + + /* + * Some SNB BIOSen (eg. ASUS K53SV) are known to misprogram + * the hardware when a high res displays plugged in. DPLL P + * divider is zero, and the pipe timings are bonkers. We'll + * try to disable everything in that case. + * + * FIXME would be nice to be able to sanitize this state + * without several WARNs, but for now let's take the easy + * road. + */ + return IS_GEN(dev_priv, 6) && + crtc_state && + crtc_state->base.active && + crtc_state->shared_dpll && + crtc_state->port_clock == 0; +} + static void intel_sanitize_encoder(struct intel_encoder *encoder) { struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); struct intel_connector *connector; + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc); + struct intel_crtc_state *crtc_state = crtc ? + to_intel_crtc_state(crtc->base.state) : NULL; /* We need to check both for a crtc link (meaning that the * encoder is active and trying to read from a pipe) and the * pipe itself being active. */ - bool has_active_crtc = encoder->base.crtc && - to_intel_crtc(encoder->base.crtc)->active; + bool has_active_crtc = crtc_state && + crtc_state->base.active; + + if (has_bogus_dpll_config(crtc_state)) { + DRM_DEBUG_KMS("BIOS has misprogrammed the hardware. Disabling pipe %c\n", + pipe_name(crtc->pipe)); + has_active_crtc = false; + } connector = intel_encoder_find_connector(encoder); if (connector && !has_active_crtc) { @@ -15455,16 +15485,25 @@ static void intel_sanitize_encoder(struct intel_encoder *encoder) /* Connector is active, but has no active pipe. This is * fallout from our resume register restoring. Disable * the encoder manually again. */ - if (encoder->base.crtc) { - struct drm_crtc_state *crtc_state = encoder->base.crtc->state; + if (crtc_state) { + struct drm_encoder *best_encoder; DRM_DEBUG_KMS("[ENCODER:%d:%s] manually disabled\n", encoder->base.base.id, encoder->base.name); + + /* avoid oopsing in case the hooks consult best_encoder */ + best_encoder = connector->base.state->best_encoder; + connector->base.state->best_encoder = &encoder->base; + if (encoder->disable) - encoder->disable(encoder, to_intel_crtc_state(crtc_state), connector->base.state); + encoder->disable(encoder, crtc_state, + connector->base.state); if (encoder->post_disable) - encoder->post_disable(encoder, to_intel_crtc_state(crtc_state), connector->base.state); + encoder->post_disable(encoder, crtc_state, + connector->base.state); + + connector->base.state->best_encoder = best_encoder; } encoder->base.crtc = NULL; -- 2.19.2

6 years, 8 months

4
4
0 0

[PATCH v3] ipmi_si: fix use-after-free of resource->name

by Yang Yingliang

When we excute the following commands, we got oops rmmod ipmi_si cat /proc/ioports [ 1623.482380] Unable to handle kernel paging request at virtual address ffff00000901d478 [ 1623.482382] Mem abort info: [ 1623.482383] ESR = 0x96000007 [ 1623.482385] Exception class = DABT (current EL), IL = 32 bits [ 1623.482386] SET = 0, FnV = 0 [ 1623.482387] EA = 0, S1PTW = 0 [ 1623.482388] Data abort info: [ 1623.482389] ISV = 0, ISS = 0x00000007 [ 1623.482390] CM = 0, WnR = 0 [ 1623.482393] swapper pgtable: 4k pages, 48-bit VAs, pgdp = 00000000d7d94a66 [ 1623.482395] [ffff00000901d478] pgd=000000dffbfff003, pud=000000dffbffe003, pmd=0000003f5d06e003, pte=0000000000000000 [ 1623.482399] Internal error: Oops: 96000007 [#1] SMP [ 1623.487407] Modules linked in: ipmi_si(E) nls_utf8 isofs rpcrdma ib_iser ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_umad rdma_cm ib_cm dm_mirror dm_region_hash dm_log iw_cm dm_mod aes_ce_blk crypto_simd cryptd aes_ce_cipher ses ghash_ce sha2_ce enclosure sha256_arm64 sg sha1_ce hisi_sas_v2_hw hibmc_drm sbsa_gwdt hisi_sas_main ip_tables mlx5_ib ib_uverbs marvell ib_core mlx5_core ixgbe mdio hns_dsaf ipmi_devintf hns_enet_drv ipmi_msghandler hns_mdio [last unloaded: ipmi_si] [ 1623.532410] CPU: 30 PID: 11438 Comm: cat Kdump: loaded Tainted: G E 5.0.0-rc3+ #168 [ 1623.541498] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.37 11/21/2017 [ 1623.548822] pstate: a0000005 (NzCv daif -PAN -UAO) [ 1623.553684] pc : string+0x28/0x98 [ 1623.557040] lr : vsnprintf+0x368/0x5e8 [ 1623.560837] sp : ffff000013213a80 [ 1623.564191] x29: ffff000013213a80 x28: ffff00001138abb5 [ 1623.569577] x27: ffff000013213c18 x26: ffff805f67d06049 [ 1623.574963] x25: 0000000000000000 x24: ffff00001138abb5 [ 1623.580349] x23: 0000000000000fb7 x22: ffff0000117ed000 [ 1623.585734] x21: ffff000011188fd8 x20: ffff805f67d07000 [ 1623.591119] x19: ffff805f67d06061 x18: ffffffffffffffff [ 1623.596505] x17: 0000000000000200 x16: 0000000000000000 [ 1623.601890] x15: ffff0000117ed748 x14: ffff805f67d07000 [ 1623.607276] x13: ffff805f67d0605e x12: 0000000000000000 [ 1623.612661] x11: 0000000000000000 x10: 0000000000000000 [ 1623.618046] x9 : 0000000000000000 x8 : 000000000000000f [ 1623.623432] x7 : ffff805f67d06061 x6 : fffffffffffffffe [ 1623.628817] x5 : 0000000000000012 x4 : ffff00000901d478 [ 1623.634203] x3 : ffff0a00ffffff04 x2 : ffff805f67d07000 [ 1623.639588] x1 : ffff805f67d07000 x0 : ffffffffffffffff [ 1623.644974] Process cat (pid: 11438, stack limit = 0x000000008d4cbc10) [ 1623.651592] Call trace: [ 1623.654068] string+0x28/0x98 [ 1623.657071] vsnprintf+0x368/0x5e8 [ 1623.660517] seq_vprintf+0x70/0x98 [ 1623.668009] seq_printf+0x7c/0xa0 [ 1623.675530] r_show+0xc8/0xf8 [ 1623.682558] seq_read+0x330/0x440 [ 1623.689877] proc_reg_read+0x78/0xd0 [ 1623.697346] __vfs_read+0x60/0x1a0 [ 1623.704564] vfs_read+0x94/0x150 [ 1623.711339] ksys_read+0x6c/0xd8 [ 1623.717939] __arm64_sys_read+0x24/0x30 [ 1623.725077] el0_svc_common+0x120/0x148 [ 1623.732035] el0_svc_handler+0x30/0x40 [ 1623.738757] el0_svc+0x8/0xc [ 1623.744520] Code: d1000406 aa0103e2 54000149 b4000080 (39400085) [ 1623.753441] ---[ end trace f91b6a4937de9835 ]--- [ 1623.760871] Kernel panic - not syncing: Fatal exception [ 1623.768935] SMP: stopping secondary CPUs [ 1623.775718] Kernel Offset: disabled [ 1623.781998] CPU features: 0x002,21006008 [ 1623.788777] Memory Limit: none [ 1623.798329] Starting crashdump kernel... [ 1623.805202] Bye! If io_setup is called successful in try_smi_init() but try_smi_init() goes out_err before calling ipmi_register_smi(), so ipmi_unregister_smi() will not be called while removing module. It leads to the resource that allocated in io_setup() can not be freed, but the name(DEVICE_NAME) of resource is freed while removing the module. It causes use-after-free when cat /proc/ioports. Fix this by calling io_cleanup() while try_smi_init() goes to out_err. and don't call io_cleanup() until io_setup() returns successful to avoid warning prints. Fixes: 93c303d2045b ("ipmi_si: Clean up shutdown a bit") Cc: stable(a)vger.kernel.org Reported-by: NuoHan Qiao <qiaonuohan(a)huawei.com> Suggested-by: Corey Minyard <cminyard(a)mvista.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/char/ipmi/ipmi_si_intf.c | 5 +++++ drivers/char/ipmi/ipmi_si_mem_io.c | 5 +++-- drivers/char/ipmi/ipmi_si_port_io.c | 5 +++-- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c index dc8603d..f1b9fda 100644 --- a/drivers/char/ipmi/ipmi_si_intf.c +++ b/drivers/char/ipmi/ipmi_si_intf.c @@ -2085,6 +2085,11 @@ static int try_smi_init(struct smi_info *new_smi) WARN_ON(new_smi->io.dev->init_name != NULL); out_err: + if (rv && new_smi->io.io_cleanup) { + new_smi->io.io_cleanup(&new_smi->io); + new_smi->io.io_cleanup = NULL; + } + kfree(init_name); return rv; } diff --git a/drivers/char/ipmi/ipmi_si_mem_io.c b/drivers/char/ipmi/ipmi_si_mem_io.c index fd0ec8d..7558361 100644 --- a/drivers/char/ipmi/ipmi_si_mem_io.c +++ b/drivers/char/ipmi/ipmi_si_mem_io.c @@ -81,8 +81,6 @@ int ipmi_si_mem_setup(struct si_sm_io *io) if (!addr) return -ENODEV; - io->io_cleanup = mem_cleanup; - /* * Figure out the actual readb/readw/readl/etc routine to use based * upon the register size. @@ -141,5 +139,8 @@ int ipmi_si_mem_setup(struct si_sm_io *io) mem_region_cleanup(io, io->io_size); return -EIO; } + + io->io_cleanup = mem_cleanup; + return 0; } diff --git a/drivers/char/ipmi/ipmi_si_port_io.c b/drivers/char/ipmi/ipmi_si_port_io.c index ef6dffc..03924c3 100644 --- a/drivers/char/ipmi/ipmi_si_port_io.c +++ b/drivers/char/ipmi/ipmi_si_port_io.c @@ -68,8 +68,6 @@ int ipmi_si_port_setup(struct si_sm_io *io) if (!addr) return -ENODEV; - io->io_cleanup = port_cleanup; - /* * Figure out the actual inb/inw/inl/etc routine to use based * upon the register size. @@ -109,5 +107,8 @@ int ipmi_si_port_setup(struct si_sm_io *io) return -EIO; } } + + io->io_cleanup = port_cleanup; + return 0; } -- 1.8.3

6 years, 8 months

2
1
0 0

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 9f1a389a0b5b Linux 4.20.5 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 9f1a389a0b5b Linux 4.20.5 We then merged the following patches with `git am`: amd-xgbe-fix-mdio-access-for-non-zero-ports-and-clause-45-phys.patch net-bridge-fix-ethernet-header-pointer-before-check-skb-forwardable.patch net-fix-usage-of-pskb_trim_rcsum.patch net-phy-marvell-errata-for-mv88e6390-internal-phys.patch net-phy-mdio_bus-add-missing-device_del-in-mdiobus_register-error-handling.patch net-phy-phy-driver-features-are-mandatory.patch net-sched-act_tunnel_key-fix-memory-leak-in-case-of-action-replace.patch net_sched-refetch-skb-protocol-for-each-filter.patch openvswitch-avoid-oob-read-when-parsing-flow-nlattrs.patch vhost-log-dirty-page-correctly.patch mlxsw-pci-increase-pci-sw-reset-timeout.patch net-ipv4-fix-memory-leak-in-network-namespace-dismantle.patch mlxsw-spectrum_fid-update-dummy-fid-index.patch mlxsw-pci-ring-cq-s-doorbell-before-rdq-s.patch net-sched-cls_flower-allocate-mask-dynamically-in-fl_change.patch udp-with-udp_segment-release-on-error-path.patch ip6_gre-fix-tunnel-list-corruption-for-x-netns.patch erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch net-phy-marvell-fix-deadlock-from-wrong-locking.patch ip6_gre-update-version-related-info-when-changing-link.patch tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch arm-fix-the-cockup-in-the-previous-patch.patch sunrpc-address-kerberos-performance-behavior-regress.patch mei-me-mark-lbg-devices-as-having-dma-support.patch mei-me-add-denverton-innovation-engine-device-ids.patch usb-leds-fix-regression-in-usbport-led-trigger.patch usb-ehci-ehci-mv-add-module_device_table.patch usb-serial-ftdi_sio-fix-gpio-not-working-in-autosuspend.patch usb-serial-simple-add-motorola-tetra-tpg2200-device-id.patch usb-serial-pl2303-add-new-pid-to-support-pl2303tb.patch ceph-clear-inode-pointer-when-snap-realm-gets-dropped-by-its-inode.patch asoc-atom-fix-a-missing-check-of-snd_pcm_lib_malloc_pages.patch asoc-rt5514-spi-fix-potential-null-pointer-dereference.patch asoc-tlv320aic32x4-kernel-oops-while-entering-dapm-standby-mode.patch clk-zynqmp-fix-memory-allocation-in-zynqmp_clk_setup.patch clk-socfpga-stratix10-fix-rate-calculation-for-pll-clocks.patch clk-socfpga-stratix10-fix-naming-convention-for-the-fixed-clocks.patch inotify-fix-fd-refcount-leak-in-inotify_add_watch.patch alsa-hda-realtek-fix-typo-for-alc225-model.patch alsa-hda-add-mute-led-support-for-hp-probook-470-g5.patch arcv2-lib-memeset-fix-doing-prefetchw-outside-of-buffer.patch arc-adjust-memblock_reserve-of-kernel-memory.patch arc-perf-map-generic-branches-to-correct-hardware-condition.patch s390-vdso-correct-vdso-mapping-for-compat-tasks.patch s390-mm-always-force-a-load-of-the-primary-asce-on-context-switch.patch s390-early-improve-machine-detection.patch s390-smp-fix-cpu-hotplug-deadlock-with-cpu-rescan.patch s390-smp-fix-calling-smp_call_ipl_cpu-from-ipl-cpu.patch misc-ibmvsm-fix-potential-null-pointer-dereference.patch char-mwave-fix-potential-spectre-v1-vulnerability.patch mmc-sdhci-iproc-handle-mmc_of_parse-errors-during-probe.patch mmc-dw_mmc-bluefield-fix-the-license-information.patch mmc-meson-gx-free-irq-in-release-callback.patch staging-rtl8188eu-add-device-code-for-d-link-dwa-121-rev-b1.patch tty-handle-problem-if-line-discipline-does-not-have-receive_buf.patch uart-fix-crash-in-uart_write-and-uart_put_char.patch tty-n_hdlc-fix-__might_sleep-warning.patch hv_balloon-avoid-touching-uninitialized-struct-page-during-tail-onlining.patch drivers-hv-vmbus-check-for-ring-when-getting-debug-info.patch vgacon-unconfuse-vc_origin-when-using-soft-scrollback.patch cifs-fix-possible-hang-during-async-mtu-reads-and-writes.patch cifs-fix-credits-calculations-for-reads-with-errors.patch cifs-fix-credit-calculation-for-encrypted-reads-with-errors.patch cifs-do-not-reconnect-tcp-session-in-add_credits.patch smb3-add-credits-we-receive-from-oplock-break-pdus.patch Compile testing --------------- We compiled the kernel for 4 architectures: s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/6f13f4a65aef27bf2905a6ca2723… powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/726e7736947c561f56e06f9502… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/bf054760715f204fa5be8e0c69… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/2f1addd560d3464a98ea585ef1c… Hardware testing ---------------- We booted each kernel and ran the following tests: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu powerpc: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 60f1bf29c0b2519989927cae640cd1f50f59dc7f Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Fri, 11 Jan 2019 15:18:22 +0100 Subject: [PATCH] s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU When calling smp_call_ipl_cpu() from the IPL CPU, we will try to read from pcpu_devices->lowcore. However, due to prefixing, that will result in reading from absolute address 0 on that CPU. We have to go via the actual lowcore instead. This means that right now, we will read lc->nodat_stack == 0 and therfore work on a very wrong stack. This BUG essentially broke rebooting under QEMU TCG (which will report a low address protection exception). And checking under KVM, it is also broken under KVM. With 1 VCPU it can be easily triggered. :/# echo 1 > /proc/sys/kernel/sysrq :/# echo b > /proc/sysrq-trigger [ 28.476745] sysrq: SysRq : Resetting [ 28.476793] Kernel stack overflow. [ 28.476817] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13 [ 28.476820] Hardware name: IBM 2964 NE1 716 (KVM/Linux) [ 28.476826] Krnl PSW : 0400c00180000000 0000000000115c0c (pcpu_delegate+0x12c/0x140) [ 28.476861] R:0 T:1 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 [ 28.476863] Krnl GPRS: ffffffffffffffff 0000000000000000 000000000010dff8 0000000000000000 [ 28.476864] 0000000000000000 0000000000000000 0000000000ab7090 000003e0006efbf0 [ 28.476864] 000000000010dff8 0000000000000000 0000000000000000 0000000000000000 [ 28.476865] 000000007fffc000 0000000000730408 000003e0006efc58 0000000000000000 [ 28.476887] Krnl Code: 0000000000115bfe: 4170f000 la %r7,0(%r15) [ 28.476887] 0000000000115c02: 41f0a000 la %r15,0(%r10) [ 28.476887] #0000000000115c06: e370f0980024 stg %r7,152(%r15) [ 28.476887] >0000000000115c0c: c0e5fffff86e brasl %r14,114ce8 [ 28.476887] 0000000000115c12: 41f07000 la %r15,0(%r7) [ 28.476887] 0000000000115c16: a7f4ffa8 brc 15,115b66 [ 28.476887] 0000000000115c1a: 0707 bcr 0,%r7 [ 28.476887] 0000000000115c1c: 0707 bcr 0,%r7 [ 28.476901] Call Trace: [ 28.476902] Last Breaking-Event-Address: [ 28.476920] [<0000000000a01c4a>] arch_call_rest_init+0x22/0x80 [ 28.476927] Kernel panic - not syncing: Corrupt kernel stack, can't continue. [ 28.476930] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13 [ 28.476932] Hardware name: IBM 2964 NE1 716 (KVM/Linux) [ 28.476932] Call Trace: Fixes: 2f859d0dad81 ("s390/smp: reduce size of struct pcpu") Cc: stable(a)vger.kernel.org # 4.0+ Reported-by: Cornelia Huck <cohuck(a)redhat.com> Signed-off-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c index 307a1c86ea21..b198ece2aad6 100644 --- a/arch/s390/kernel/smp.c +++ b/arch/s390/kernel/smp.c @@ -381,8 +381,13 @@ void smp_call_online_cpu(void (*func)(void *), void *data) */ void smp_call_ipl_cpu(void (*func)(void *), void *data) { + struct lowcore *lc = pcpu_devices->lowcore; + + if (pcpu_devices[0].address == stap()) + lc = &S390_lowcore; + pcpu_delegate(&pcpu_devices[0], func, data, - pcpu_devices->lowcore->nodat_stack); + lc->nodat_stack); } int smp_find_processor_id(u16 address)

6 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] x86/entry/64/compat: Fix stack switching for XEN PV" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From fc24d75a7f91837d7918e40719575951820b2b8f Mon Sep 17 00:00:00 2001 From: Jan Beulich <JBeulich(a)suse.com> Date: Tue, 15 Jan 2019 09:58:16 -0700 Subject: [PATCH] x86/entry/64/compat: Fix stack switching for XEN PV While in the native case entry into the kernel happens on the trampoline stack, PV Xen kernels get entered with the current thread stack right away. Hence source and destination stacks are identical in that case, and special care is needed. Other than in sync_regs() the copying done on the INT80 path isn't NMI / #MC safe, as either of these events occurring in the middle of the stack copying would clobber data on the (source) stack. There is similar code in interrupt_entry() and nmi(), but there is no fixup required because those code paths are unreachable in XEN PV guests. [ tglx: Sanitized subject, changelog, Fixes tag and stable mail address. Sigh ] Fixes: 7f2590a110b8 ("x86/entry/64: Use a per-CPU trampoline stack for IDT entries") Signed-off-by: Jan Beulich <jbeulich(a)suse.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Juergen Gross <jgross(a)suse.com> Acked-by: Andy Lutomirski <luto(a)kernel.org> Cc: Peter Anvin <hpa(a)zytor.com> Cc: xen-devel(a)lists.xenproject.org> Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Cc: stable(a)vger.kernel.org Link: https://lkml.kernel.org/r/5C3E1128020000780020DFAD@prv1-mh.provo.novell.com diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index 8eaf8952c408..39913770a44d 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -361,7 +361,8 @@ ENTRY(entry_INT80_compat) /* Need to switch before accessing the thread stack. */ SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi - movq %rsp, %rdi + /* In the Xen PV case we already run on the thread stack. */ + ALTERNATIVE "movq %rsp, %rdi", "jmp .Lint80_keep_stack", X86_FEATURE_XENPV movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp pushq 6*8(%rdi) /* regs->ss */ @@ -370,8 +371,9 @@ ENTRY(entry_INT80_compat) pushq 3*8(%rdi) /* regs->cs */ pushq 2*8(%rdi) /* regs->ip */ pushq 1*8(%rdi) /* regs->orig_ax */ - pushq (%rdi) /* pt_regs->di */ +.Lint80_keep_stack: + pushq %rsi /* pt_regs->si */ xorl %esi, %esi /* nospec si */ pushq %rdx /* pt_regs->dx */

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] x86/pkeys: Properly copy pkey state at fork()" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a31e184e4f69965c99c04cc5eb8a4920e0c63737 Mon Sep 17 00:00:00 2001 From: Dave Hansen <dave.hansen(a)linux.intel.com> Date: Wed, 2 Jan 2019 13:56:55 -0800 Subject: [PATCH] x86/pkeys: Properly copy pkey state at fork() Memory protection key behavior should be the same in a child as it was in the parent before a fork. But, there is a bug that resets the state in the child at fork instead of preserving it. The creation of new mm's is a bit convoluted. At fork(), the code does: 1. memcpy() the parent mm to initialize child 2. mm_init() to initalize some select stuff stuff 3. dup_mmap() to create true copies that memcpy() did not do right For pkeys two bits of state need to be preserved across a fork: 'execute_only_pkey' and 'pkey_allocation_map'. Those are preserved by the memcpy(), but mm_init() invokes init_new_context() which overwrites 'execute_only_pkey' and 'pkey_allocation_map' with "new" values. The author of the code erroneously believed that init_new_context is *only* called at execve()-time. But, alas, init_new_context() is used at execve() and fork(). The result is that, after a fork(), the child's pkey state ends up looking like it does after an execve(), which is totally wrong. pkeys that are already allocated can be allocated again, for instance. To fix this, add code called by dup_mmap() to copy the pkey state from parent to child explicitly. Also add a comment above init_new_context() to make it more clear to the next poor sod what this code is used for. Fixes: e8c24d3a23a ("x86/pkeys: Allocation/free syscalls") Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: bp(a)alien8.de Cc: hpa(a)zytor.com Cc: peterz(a)infradead.org Cc: mpe(a)ellerman.id.au Cc: will.deacon(a)arm.com Cc: luto(a)kernel.org Cc: jroedel(a)suse.de Cc: stable(a)vger.kernel.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Joerg Roedel <jroedel(a)suse.de> Link: https://lkml.kernel.org/r/20190102215655.7A69518C@viggo.jf.intel.com diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h index 0ca50611e8ce..19d18fae6ec6 100644 --- a/arch/x86/include/asm/mmu_context.h +++ b/arch/x86/include/asm/mmu_context.h @@ -178,6 +178,10 @@ static inline void switch_ldt(struct mm_struct *prev, struct mm_struct *next) void enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk); +/* + * Init a new mm. Used on mm copies, like at fork() + * and on mm's that are brand-new, like at execve(). + */ static inline int init_new_context(struct task_struct *tsk, struct mm_struct *mm) { @@ -228,8 +232,22 @@ do { \ } while (0) #endif +static inline void arch_dup_pkeys(struct mm_struct *oldmm, + struct mm_struct *mm) +{ +#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS + if (!cpu_feature_enabled(X86_FEATURE_OSPKE)) + return; + + /* Duplicate the oldmm pkey state in mm: */ + mm->context.pkey_allocation_map = oldmm->context.pkey_allocation_map; + mm->context.execute_only_pkey = oldmm->context.execute_only_pkey; +#endif +} + static inline int arch_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm) { + arch_dup_pkeys(oldmm, mm); paravirt_arch_dup_mmap(oldmm, mm); return ldt_dup_context(oldmm, mm); }

6 years, 8 months

1
0
0 0

[stable-4.19] KVM/nVMX: Do not validate that posted_intr_desc_addr is page aligned

by Mark Mielke

This commit was first released with 4.20: commit 22a7cdcae6a4a3c8974899e62851d270956f58ce Author: KarimAllah Ahmed <karahmed(a)amazon.de> Date: Sat Oct 20 23:42:59 2018 +0200 KVM/nVMX: Do not validate that posted_intr_desc_addr is page aligned The spec only requires the posted interrupt descriptor address to be 64-bytes aligned (i.e. bits[0:5] == 0). Using page_address_valid also forces the address to be page aligned. Only validate that the address does not cross the maximum physical address without enforcing a page alignment. This commit applies clean to 4.19. Without this commit, nested virtualization is broken in 4.19 for some use cases. In my case, a simple virt-install within the L1 guest failed to start with "KVM: entry failed, hardware error 0x7". I found another user with the same symptoms here: https://bugzilla.redhat.com/show_bug.cgi?id=1657296 After applying the above patch to 4.19.18, virt-install within the L1 guest proceeded as expected. Thank you! -- Mark Mielke <mark.mielke(a)gmail.com>

6 years, 8 months

2
1
0 0

[PATCH] drm/i915: Don't send MST hotplugs until after resume

by Lyude Paul

Turns out we are sending a lot more hotplug events then we need, and this is causing some pretty serious issues. Currently, we call intel_dp_mst_resume() in i915_drm_resume() well before we have any sort of hotplugging setup. This is a pretty big problem, because in practice it will generally result in throwing the power domain refcounts out of wack. For instance: On my T480s, removing a previously connected topology before the system finishes resuming causes drm_kms_helper_hotplug_event() to be called before HPD is setup again, which causes us to do a connector reprobe, which then causes intel_dp_detect() to be called on all DP devices -including- the eDP display. From there, intel_dp_detect() is run on the eDP display which triggers DPCD transactions. Those DPCD transactions then cause us to call edp_panel_vdd_on(), which then causes us to grab an additional wakeref to the relevant power wells (PORT_DDI_A_IO on this machine). >From there, this wakeref is never released which then causes the next suspend/resume cycle to entirely fail due to the hardware not being powered off correctly. This sucks really badly, and I don't see any decent way to actually fix this in intel_dp_detect() easily. Additionally, I don't even think it'd be worth the time now since we're not expecting to handle any kind of connector reprobing at the point in which we call intel_dp_mst_resume(), but we also can't move intel_dp_mst_resume() any higher in the resume process since MST topologies need to be resumed before intel_display_resume() is called. However, there's a light at the end of the tunnel! After reading through a lot of code dozens of times, it occurred to me that we -never- actually need to send hotplug events when calling drm_dp_mst_topology_mgr_set_mst() since we send hotplug events in drm_dp_destroy_connector_work(). Imagine that! So, since we only seem to call intel_dp_mst_check_status() to disable MST on the encoder in question and then send a hotplug, get rid of this and instead just disable MST mode when a hub fails in intel_dp_mst_resume(). From there, drm_dp_destroy_connector_work() will eventually send the hotplug event. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)") Cc: Todd Previte <tprevite(a)gmail.com> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: intel-gfx(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v3.17+ --- drivers/gpu/drm/i915/intel_dp.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 681e88405ada..c2399acf177b 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -7096,7 +7096,10 @@ void intel_dp_mst_resume(struct drm_i915_private *dev_priv) continue; ret = drm_dp_mst_topology_mgr_resume(&intel_dp->mst_mgr); - if (ret) - intel_dp_check_mst_status(intel_dp); + if (ret) { + intel_dp->is_mst = false; + drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr, + false); + } } } -- 2.20.1

6 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] dm: fix redundant IO accounting for bios that need splitting" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a1e1cb72d96491277ede8d257ce6b48a381dd336 Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer(a)redhat.com> Date: Thu, 17 Jan 2019 10:48:01 -0500 Subject: [PATCH] dm: fix redundant IO accounting for bios that need splitting The risk of redundant IO accounting was not taken into consideration when commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") introduced IO splitting in terms of recursion via generic_make_request(). Fix this by subtracting the split bio's payload from the IO stats that were already accounted for by start_io_acct() upon dm_make_request() entry. This repeat oscillation of the IO accounting, up then down, isn't ideal but refactoring DM core's IO splitting to pre-split bios _before_ they are accounted turned out to be an excessive amount of change that will need a full development cycle to refine and verify. Before this fix: /dev/mapper/stripe_dev is a 4-way stripe using a 32k chunksize, so bios are split on 32k boundaries. # fio --name=16M --filename=/dev/mapper/stripe_dev --rw=write --bs=64k --size=16M \ --iodepth=1 --ioengine=libaio --direct=1 --refill_buffers with debugging added: [103898.310264] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=0 len=128 [103898.318704] device-mapper: core: __split_and_process_bio: recursing for following split bio: [103898.329136] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=64 len=64 ... 16M written yet 136M (278528 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 278528 After this fix: 16M written and 16M (32768 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 32768 Fixes: 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") Cc: stable(a)vger.kernel.org # 4.16+ Reported-by: Bryan Gurney <bgurney(a)redhat.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm.c b/drivers/md/dm.c index fcb97b0a5743..fbadda68e23b 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1584,6 +1584,9 @@ static void init_clone_info(struct clone_info *ci, struct mapped_device *md, ci->sector = bio->bi_iter.bi_sector; } +#define __dm_part_stat_sub(part, field, subnd) \ + (part_stat_get(part, field) -= (subnd)) + /* * Entry point to split a bio into clones and submit them to the targets. */ @@ -1638,6 +1641,19 @@ static blk_qc_t __split_and_process_bio(struct mapped_device *md, struct bio *b = bio_split(bio, bio_sectors(bio) - ci.sector_count, GFP_NOIO, &md->queue->bio_split); ci.io->orig_bio = b; + + /* + * Adjust IO stats for each split, otherwise upon queue + * reentry there will be redundant IO accounting. + * NOTE: this is a stop-gap fix, a proper fix involves + * significant refactoring of DM core's bio splitting + * (by eliminating DM's splitting and just using bio_split) + */ + part_stat_lock(); + __dm_part_stat_sub(&dm_disk(md)->part0, + sectors[op_stat_group(bio_op(bio))], ci.sector_count); + part_stat_unlock(); + bio_chain(b, bio); ret = generic_make_request(bio); break;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] dm: fix redundant IO accounting for bios that need splitting" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a1e1cb72d96491277ede8d257ce6b48a381dd336 Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer(a)redhat.com> Date: Thu, 17 Jan 2019 10:48:01 -0500 Subject: [PATCH] dm: fix redundant IO accounting for bios that need splitting The risk of redundant IO accounting was not taken into consideration when commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") introduced IO splitting in terms of recursion via generic_make_request(). Fix this by subtracting the split bio's payload from the IO stats that were already accounted for by start_io_acct() upon dm_make_request() entry. This repeat oscillation of the IO accounting, up then down, isn't ideal but refactoring DM core's IO splitting to pre-split bios _before_ they are accounted turned out to be an excessive amount of change that will need a full development cycle to refine and verify. Before this fix: /dev/mapper/stripe_dev is a 4-way stripe using a 32k chunksize, so bios are split on 32k boundaries. # fio --name=16M --filename=/dev/mapper/stripe_dev --rw=write --bs=64k --size=16M \ --iodepth=1 --ioengine=libaio --direct=1 --refill_buffers with debugging added: [103898.310264] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=0 len=128 [103898.318704] device-mapper: core: __split_and_process_bio: recursing for following split bio: [103898.329136] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=64 len=64 ... 16M written yet 136M (278528 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 278528 After this fix: 16M written and 16M (32768 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 32768 Fixes: 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") Cc: stable(a)vger.kernel.org # 4.16+ Reported-by: Bryan Gurney <bgurney(a)redhat.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm.c b/drivers/md/dm.c index fcb97b0a5743..fbadda68e23b 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1584,6 +1584,9 @@ static void init_clone_info(struct clone_info *ci, struct mapped_device *md, ci->sector = bio->bi_iter.bi_sector; } +#define __dm_part_stat_sub(part, field, subnd) \ + (part_stat_get(part, field) -= (subnd)) + /* * Entry point to split a bio into clones and submit them to the targets. */ @@ -1638,6 +1641,19 @@ static blk_qc_t __split_and_process_bio(struct mapped_device *md, struct bio *b = bio_split(bio, bio_sectors(bio) - ci.sector_count, GFP_NOIO, &md->queue->bio_split); ci.io->orig_bio = b; + + /* + * Adjust IO stats for each split, otherwise upon queue + * reentry there will be redundant IO accounting. + * NOTE: this is a stop-gap fix, a proper fix involves + * significant refactoring of DM core's bio splitting + * (by eliminating DM's splitting and just using bio_split) + */ + part_stat_lock(); + __dm_part_stat_sub(&dm_disk(md)->part0, + sectors[op_stat_group(bio_op(bio))], ci.sector_count); + part_stat_unlock(); + bio_chain(b, bio); ret = generic_make_request(bio); break;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] dm: fix redundant IO accounting for bios that need splitting" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a1e1cb72d96491277ede8d257ce6b48a381dd336 Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer(a)redhat.com> Date: Thu, 17 Jan 2019 10:48:01 -0500 Subject: [PATCH] dm: fix redundant IO accounting for bios that need splitting The risk of redundant IO accounting was not taken into consideration when commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") introduced IO splitting in terms of recursion via generic_make_request(). Fix this by subtracting the split bio's payload from the IO stats that were already accounted for by start_io_acct() upon dm_make_request() entry. This repeat oscillation of the IO accounting, up then down, isn't ideal but refactoring DM core's IO splitting to pre-split bios _before_ they are accounted turned out to be an excessive amount of change that will need a full development cycle to refine and verify. Before this fix: /dev/mapper/stripe_dev is a 4-way stripe using a 32k chunksize, so bios are split on 32k boundaries. # fio --name=16M --filename=/dev/mapper/stripe_dev --rw=write --bs=64k --size=16M \ --iodepth=1 --ioengine=libaio --direct=1 --refill_buffers with debugging added: [103898.310264] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=0 len=128 [103898.318704] device-mapper: core: __split_and_process_bio: recursing for following split bio: [103898.329136] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=64 len=64 ... 16M written yet 136M (278528 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 278528 After this fix: 16M written and 16M (32768 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 32768 Fixes: 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") Cc: stable(a)vger.kernel.org # 4.16+ Reported-by: Bryan Gurney <bgurney(a)redhat.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm.c b/drivers/md/dm.c index fcb97b0a5743..fbadda68e23b 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1584,6 +1584,9 @@ static void init_clone_info(struct clone_info *ci, struct mapped_device *md, ci->sector = bio->bi_iter.bi_sector; } +#define __dm_part_stat_sub(part, field, subnd) \ + (part_stat_get(part, field) -= (subnd)) + /* * Entry point to split a bio into clones and submit them to the targets. */ @@ -1638,6 +1641,19 @@ static blk_qc_t __split_and_process_bio(struct mapped_device *md, struct bio *b = bio_split(bio, bio_sectors(bio) - ci.sector_count, GFP_NOIO, &md->queue->bio_split); ci.io->orig_bio = b; + + /* + * Adjust IO stats for each split, otherwise upon queue + * reentry there will be redundant IO accounting. + * NOTE: this is a stop-gap fix, a proper fix involves + * significant refactoring of DM core's bio splitting + * (by eliminating DM's splitting and just using bio_split) + */ + part_stat_lock(); + __dm_part_stat_sub(&dm_disk(md)->part0, + sectors[op_stat_group(bio_op(bio))], ci.sector_count); + part_stat_unlock(); + bio_chain(b, bio); ret = generic_make_request(bio); break;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] dm: fix redundant IO accounting for bios that need splitting" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a1e1cb72d96491277ede8d257ce6b48a381dd336 Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer(a)redhat.com> Date: Thu, 17 Jan 2019 10:48:01 -0500 Subject: [PATCH] dm: fix redundant IO accounting for bios that need splitting The risk of redundant IO accounting was not taken into consideration when commit 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") introduced IO splitting in terms of recursion via generic_make_request(). Fix this by subtracting the split bio's payload from the IO stats that were already accounted for by start_io_acct() upon dm_make_request() entry. This repeat oscillation of the IO accounting, up then down, isn't ideal but refactoring DM core's IO splitting to pre-split bios _before_ they are accounted turned out to be an excessive amount of change that will need a full development cycle to refine and verify. Before this fix: /dev/mapper/stripe_dev is a 4-way stripe using a 32k chunksize, so bios are split on 32k boundaries. # fio --name=16M --filename=/dev/mapper/stripe_dev --rw=write --bs=64k --size=16M \ --iodepth=1 --ioengine=libaio --direct=1 --refill_buffers with debugging added: [103898.310264] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=0 len=128 [103898.318704] device-mapper: core: __split_and_process_bio: recursing for following split bio: [103898.329136] device-mapper: core: start_io_acct: dm-2 WRITE bio->bi_iter.bi_sector=64 len=64 ... 16M written yet 136M (278528 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 278528 After this fix: 16M written and 16M (32768 * 512b) accounted: # cat /sys/block/dm-2/stat | awk '{ print $7 }' 32768 Fixes: 18a25da84354 ("dm: ensure bio submission follows a depth-first tree walk") Cc: stable(a)vger.kernel.org # 4.16+ Reported-by: Bryan Gurney <bgurney(a)redhat.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm.c b/drivers/md/dm.c index fcb97b0a5743..fbadda68e23b 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1584,6 +1584,9 @@ static void init_clone_info(struct clone_info *ci, struct mapped_device *md, ci->sector = bio->bi_iter.bi_sector; } +#define __dm_part_stat_sub(part, field, subnd) \ + (part_stat_get(part, field) -= (subnd)) + /* * Entry point to split a bio into clones and submit them to the targets. */ @@ -1638,6 +1641,19 @@ static blk_qc_t __split_and_process_bio(struct mapped_device *md, struct bio *b = bio_split(bio, bio_sectors(bio) - ci.sector_count, GFP_NOIO, &md->queue->bio_split); ci.io->orig_bio = b; + + /* + * Adjust IO stats for each split, otherwise upon queue + * reentry there will be redundant IO accounting. + * NOTE: this is a stop-gap fix, a proper fix involves + * significant refactoring of DM core's bio splitting + * (by eliminating DM's splitting and just using bio_split) + */ + part_stat_lock(); + __dm_part_stat_sub(&dm_disk(md)->part0, + sectors[op_stat_group(bio_op(bio))], ci.sector_count); + part_stat_unlock(); + bio_chain(b, bio); ret = generic_make_request(bio); break;

6 years, 8 months

1
0
0 0

[PATCH v2] Bluetooth: btrtl: Restore old logic to assume firmware is already loaded

by Kai-Heng Feng

Realtek bluetooth may not work after reboot: [ 12.446130] Bluetooth: hci0: RTL: rtl: unknown IC info, lmp subver a99e, hci rev 826c, hci ver 0008 This is a regression introduced by commit 26503ad25de8 ("Bluetooth: btrtl: split the device initialization into smaller parts"). The new logic errors out early when no matching IC info can be found, in this case it means the firmware is already loaded. So let's assume the firmware is already loaded when we can't find matching IC info, like the old logic did. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201921 Fixes: 26503ad25de8 ("Bluetooth: btrtl: split the device initialization into smaller parts") Cc: stable(a)vger.kernel.org # 4.19+ Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/bluetooth/btrtl.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c index 41405de27d66..c91bba00df4e 100644 --- a/drivers/bluetooth/btrtl.c +++ b/drivers/bluetooth/btrtl.c @@ -552,10 +552,9 @@ struct btrtl_device_info *btrtl_initialize(struct hci_dev *hdev, hdev->bus); if (!btrtl_dev->ic_info) { - rtl_dev_err(hdev, "rtl: unknown IC info, lmp subver %04x, hci rev %04x, hci ver %04x", + rtl_dev_info(hdev, "rtl: unknown IC info, lmp subver %04x, hci rev %04x, hci ver %04x", lmp_subver, hci_rev, hci_ver); - ret = -EINVAL; - goto err_free; + return btrtl_dev; } if (btrtl_dev->ic_info->has_rom_version) { @@ -610,6 +609,11 @@ int btrtl_download_firmware(struct hci_dev *hdev, * standard btusb. Once that firmware is uploaded, the subver changes * to a different value. */ + if (!btrtl_dev->ic_info) { + rtl_dev_info(hdev, "rtl: assuming no firmware upload needed\n"); + return 0; + } + switch (btrtl_dev->ic_info->lmp_subver) { case RTL_ROM_LMP_8723A: case RTL_ROM_LMP_3499: -- 2.17.1

6 years, 8 months

2
1
0 0

[PATCH v3] usb: dwc3: gadget: Handle 0 xfer length for OUT EP

by Tejas Joglekar

For OUT endpoints, zero-length transfers require MaxPacketSize buffer as per the DWC_usb3 programming guide 3.30a section 4.2.3.3. This patch fixes this by explicitly checking zero length transfer to correctly pad up to MaxPacketSize. Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable(a)vger.kernel.org Signed-off-by: Tejas Joglekar <joglekar(a)synopsys.com> --- Changes in v3: - Enclose summary for fixes with " " and no wrap Changes in v2: - Remove sg patch hunk - Added fixes and stable tag drivers/usb/dwc3/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index bed2ff4..6c9b76b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1119,7 +1119,7 @@ static void dwc3_prepare_one_trb_linear(struct dwc3_ep *dep, unsigned int maxp = usb_endpoint_maxp(dep->endpoint.desc); unsigned int rem = length % maxp; - if (rem && usb_endpoint_dir_out(dep->endpoint.desc)) { + if ((!length || rem) && usb_endpoint_dir_out(dep->endpoint.desc)) { struct dwc3 *dwc = dep->dwc; struct dwc3_trb *trb; -- 2.7.4

6 years, 8 months

1
1
0 0

FAILED: patch "[PATCH] nvmet-rdma: fix null dereference under heavy load" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 5cbab6303b4791a3e6713dfe2c5fda6a867f9adc Mon Sep 17 00:00:00 2001 From: Raju Rangoju <rajur(a)chelsio.com> Date: Thu, 3 Jan 2019 23:05:31 +0530 Subject: [PATCH] nvmet-rdma: fix null dereference under heavy load Under heavy load if we don't have any pre-allocated rsps left, we dynamically allocate a rsp, but we are not actually allocating memory for nvme_completion (rsp->req.rsp). In such a case, accessing pointer fields (req->rsp->status) in nvmet_req_init() will result in crash. To fix this, allocate the memory for nvme_completion by calling nvmet_rdma_alloc_rsp() Fixes: 8407879c("nvmet-rdma:fix possible bogus dereference under heavy load") Cc: <stable(a)vger.kernel.org> Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Raju Rangoju <rajur(a)chelsio.com> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c index a8d23eb80192..a884e3a0e8af 100644 --- a/drivers/nvme/target/rdma.c +++ b/drivers/nvme/target/rdma.c @@ -139,6 +139,10 @@ static void nvmet_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_read_data_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_qp_event(struct ib_event *event, void *priv); static void nvmet_rdma_queue_disconnect(struct nvmet_rdma_queue *queue); +static void nvmet_rdma_free_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); +static int nvmet_rdma_alloc_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); static const struct nvmet_fabrics_ops nvmet_rdma_ops; @@ -182,9 +186,17 @@ nvmet_rdma_get_rsp(struct nvmet_rdma_queue *queue) spin_unlock_irqrestore(&queue->rsps_lock, flags); if (unlikely(!rsp)) { - rsp = kmalloc(sizeof(*rsp), GFP_KERNEL); + int ret; + + rsp = kzalloc(sizeof(*rsp), GFP_KERNEL); if (unlikely(!rsp)) return NULL; + ret = nvmet_rdma_alloc_rsp(queue->dev, rsp); + if (unlikely(ret)) { + kfree(rsp); + return NULL; + } + rsp->allocated = true; } @@ -197,6 +209,7 @@ nvmet_rdma_put_rsp(struct nvmet_rdma_rsp *rsp) unsigned long flags; if (unlikely(rsp->allocated)) { + nvmet_rdma_free_rsp(rsp->queue->dev, rsp); kfree(rsp); return; }

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] nvmet-rdma: fix null dereference under heavy load" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 5cbab6303b4791a3e6713dfe2c5fda6a867f9adc Mon Sep 17 00:00:00 2001 From: Raju Rangoju <rajur(a)chelsio.com> Date: Thu, 3 Jan 2019 23:05:31 +0530 Subject: [PATCH] nvmet-rdma: fix null dereference under heavy load Under heavy load if we don't have any pre-allocated rsps left, we dynamically allocate a rsp, but we are not actually allocating memory for nvme_completion (rsp->req.rsp). In such a case, accessing pointer fields (req->rsp->status) in nvmet_req_init() will result in crash. To fix this, allocate the memory for nvme_completion by calling nvmet_rdma_alloc_rsp() Fixes: 8407879c("nvmet-rdma:fix possible bogus dereference under heavy load") Cc: <stable(a)vger.kernel.org> Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Raju Rangoju <rajur(a)chelsio.com> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c index a8d23eb80192..a884e3a0e8af 100644 --- a/drivers/nvme/target/rdma.c +++ b/drivers/nvme/target/rdma.c @@ -139,6 +139,10 @@ static void nvmet_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_read_data_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_qp_event(struct ib_event *event, void *priv); static void nvmet_rdma_queue_disconnect(struct nvmet_rdma_queue *queue); +static void nvmet_rdma_free_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); +static int nvmet_rdma_alloc_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); static const struct nvmet_fabrics_ops nvmet_rdma_ops; @@ -182,9 +186,17 @@ nvmet_rdma_get_rsp(struct nvmet_rdma_queue *queue) spin_unlock_irqrestore(&queue->rsps_lock, flags); if (unlikely(!rsp)) { - rsp = kmalloc(sizeof(*rsp), GFP_KERNEL); + int ret; + + rsp = kzalloc(sizeof(*rsp), GFP_KERNEL); if (unlikely(!rsp)) return NULL; + ret = nvmet_rdma_alloc_rsp(queue->dev, rsp); + if (unlikely(ret)) { + kfree(rsp); + return NULL; + } + rsp->allocated = true; } @@ -197,6 +209,7 @@ nvmet_rdma_put_rsp(struct nvmet_rdma_rsp *rsp) unsigned long flags; if (unlikely(rsp->allocated)) { + nvmet_rdma_free_rsp(rsp->queue->dev, rsp); kfree(rsp); return; }

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] nvmet-rdma: fix null dereference under heavy load" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 5cbab6303b4791a3e6713dfe2c5fda6a867f9adc Mon Sep 17 00:00:00 2001 From: Raju Rangoju <rajur(a)chelsio.com> Date: Thu, 3 Jan 2019 23:05:31 +0530 Subject: [PATCH] nvmet-rdma: fix null dereference under heavy load Under heavy load if we don't have any pre-allocated rsps left, we dynamically allocate a rsp, but we are not actually allocating memory for nvme_completion (rsp->req.rsp). In such a case, accessing pointer fields (req->rsp->status) in nvmet_req_init() will result in crash. To fix this, allocate the memory for nvme_completion by calling nvmet_rdma_alloc_rsp() Fixes: 8407879c("nvmet-rdma:fix possible bogus dereference under heavy load") Cc: <stable(a)vger.kernel.org> Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Raju Rangoju <rajur(a)chelsio.com> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c index a8d23eb80192..a884e3a0e8af 100644 --- a/drivers/nvme/target/rdma.c +++ b/drivers/nvme/target/rdma.c @@ -139,6 +139,10 @@ static void nvmet_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_read_data_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_qp_event(struct ib_event *event, void *priv); static void nvmet_rdma_queue_disconnect(struct nvmet_rdma_queue *queue); +static void nvmet_rdma_free_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); +static int nvmet_rdma_alloc_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); static const struct nvmet_fabrics_ops nvmet_rdma_ops; @@ -182,9 +186,17 @@ nvmet_rdma_get_rsp(struct nvmet_rdma_queue *queue) spin_unlock_irqrestore(&queue->rsps_lock, flags); if (unlikely(!rsp)) { - rsp = kmalloc(sizeof(*rsp), GFP_KERNEL); + int ret; + + rsp = kzalloc(sizeof(*rsp), GFP_KERNEL); if (unlikely(!rsp)) return NULL; + ret = nvmet_rdma_alloc_rsp(queue->dev, rsp); + if (unlikely(ret)) { + kfree(rsp); + return NULL; + } + rsp->allocated = true; } @@ -197,6 +209,7 @@ nvmet_rdma_put_rsp(struct nvmet_rdma_rsp *rsp) unsigned long flags; if (unlikely(rsp->allocated)) { + nvmet_rdma_free_rsp(rsp->queue->dev, rsp); kfree(rsp); return; }

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] nvmet-rdma: fix null dereference under heavy load" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 5cbab6303b4791a3e6713dfe2c5fda6a867f9adc Mon Sep 17 00:00:00 2001 From: Raju Rangoju <rajur(a)chelsio.com> Date: Thu, 3 Jan 2019 23:05:31 +0530 Subject: [PATCH] nvmet-rdma: fix null dereference under heavy load Under heavy load if we don't have any pre-allocated rsps left, we dynamically allocate a rsp, but we are not actually allocating memory for nvme_completion (rsp->req.rsp). In such a case, accessing pointer fields (req->rsp->status) in nvmet_req_init() will result in crash. To fix this, allocate the memory for nvme_completion by calling nvmet_rdma_alloc_rsp() Fixes: 8407879c("nvmet-rdma:fix possible bogus dereference under heavy load") Cc: <stable(a)vger.kernel.org> Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Raju Rangoju <rajur(a)chelsio.com> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c index a8d23eb80192..a884e3a0e8af 100644 --- a/drivers/nvme/target/rdma.c +++ b/drivers/nvme/target/rdma.c @@ -139,6 +139,10 @@ static void nvmet_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_read_data_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_qp_event(struct ib_event *event, void *priv); static void nvmet_rdma_queue_disconnect(struct nvmet_rdma_queue *queue); +static void nvmet_rdma_free_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); +static int nvmet_rdma_alloc_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); static const struct nvmet_fabrics_ops nvmet_rdma_ops; @@ -182,9 +186,17 @@ nvmet_rdma_get_rsp(struct nvmet_rdma_queue *queue) spin_unlock_irqrestore(&queue->rsps_lock, flags); if (unlikely(!rsp)) { - rsp = kmalloc(sizeof(*rsp), GFP_KERNEL); + int ret; + + rsp = kzalloc(sizeof(*rsp), GFP_KERNEL); if (unlikely(!rsp)) return NULL; + ret = nvmet_rdma_alloc_rsp(queue->dev, rsp); + if (unlikely(ret)) { + kfree(rsp); + return NULL; + } + rsp->allocated = true; } @@ -197,6 +209,7 @@ nvmet_rdma_put_rsp(struct nvmet_rdma_rsp *rsp) unsigned long flags; if (unlikely(rsp->allocated)) { + nvmet_rdma_free_rsp(rsp->queue->dev, rsp); kfree(rsp); return; }

6 years, 8 months

1
0
0 0

[PATCH v8 01/26] arm64: Fix HCR.TGE status for NMI contexts

by Julien Thierry

When using VHE, the host needs to clear HCR_EL2.TGE bit in order to interract with guest TLBs, switching from EL2&0 translation regime to EL1&0. However, some non-maskable asynchronous event could happen while TGE is cleared like SDEI. Because of this address translation operations relying on EL2&0 translation regime could fail (tlb invalidation, userspace access, ...). Fix this by properly setting HCR_EL2.TGE when entering NMI context and clear it if necessary when returning to the interrupted context. Signed-off-by: Julien Thierry <julien.thierry(a)arm.com> Suggested-by: Marc Zyngier <marc.zyngier(a)arm.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Marc Zyngier <marc.zyngier(a)arm.com> Cc: James Morse <james.morse(a)arm.com> Cc: linux-arch(a)vger.kernel.org Cc: stable(a)vger.kernel.org --- arch/arm64/include/asm/hardirq.h | 28 ++++++++++++++++++++++++++++ arch/arm64/kernel/irq.c | 3 +++ include/linux/hardirq.h | 7 +++++++ 3 files changed, 38 insertions(+) diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h index 1473fc2..94b7481 100644 --- a/arch/arm64/include/asm/hardirq.h +++ b/arch/arm64/include/asm/hardirq.h @@ -19,6 +19,7 @@ #include <linux/cache.h> #include <linux/threads.h> #include <asm/irq.h> +#include <asm/kvm_arm.h> #define NR_IPI 7 @@ -37,6 +38,33 @@ #define __ARCH_IRQ_EXIT_IRQS_DISABLED 1 +struct nmi_ctx { + u64 hcr; +}; + +DECLARE_PER_CPU(struct nmi_ctx, nmi_contexts); + +#define arch_nmi_enter() \ + do { \ + if (is_kernel_in_hyp_mode()) { \ + struct nmi_ctx *nmi_ctx = this_cpu_ptr(&nmi_contexts); \ + nmi_ctx->hcr = read_sysreg(hcr_el2); \ + if (!(nmi_ctx->hcr & HCR_TGE)) { \ + write_sysreg(nmi_ctx->hcr | HCR_TGE, hcr_el2); \ + isb(); \ + } \ + } \ + } while (0) + +#define arch_nmi_exit() \ + do { \ + if (is_kernel_in_hyp_mode()) { \ + struct nmi_ctx *nmi_ctx = this_cpu_ptr(&nmi_contexts); \ + if (!(nmi_ctx->hcr & HCR_TGE)) \ + write_sysreg(nmi_ctx->hcr, hcr_el2); \ + } \ + } while (0) + static inline void ack_bad_irq(unsigned int irq) { extern unsigned long irq_err_count; diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c index 780a12f..92fa817 100644 --- a/arch/arm64/kernel/irq.c +++ b/arch/arm64/kernel/irq.c @@ -33,6 +33,9 @@ unsigned long irq_err_count; +/* Only access this in an NMI enter/exit */ +DEFINE_PER_CPU(struct nmi_ctx, nmi_contexts); + DEFINE_PER_CPU(unsigned long *, irq_stack_ptr); int arch_show_interrupts(struct seq_file *p, int prec) diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h index 0fbbcdf..da0af63 100644 --- a/include/linux/hardirq.h +++ b/include/linux/hardirq.h @@ -60,8 +60,14 @@ static inline void rcu_nmi_exit(void) */ extern void irq_exit(void); +#ifndef arch_nmi_enter +#define arch_nmi_enter() do { } while (0) +#define arch_nmi_exit() do { } while (0) +#endif + #define nmi_enter() \ do { \ + arch_nmi_enter(); \ printk_nmi_enter(); \ lockdep_off(); \ ftrace_nmi_enter(); \ @@ -80,6 +86,7 @@ static inline void rcu_nmi_exit(void) ftrace_nmi_exit(); \ lockdep_on(); \ printk_nmi_exit(); \ + arch_nmi_exit(); \ } while (0) #endif /* LINUX_HARDIRQ_H */ -- 1.9.1

6 years, 8 months

4
4
0 0

Want retouching for your photos?

by Jennifer

Did you receive my email from last week? Do you have needs for retouching of your photos? We can do it white background for your pictures. If you need clipping path just let me know. You can send 1 or 2 photos for testing to judge our quality. Thanks, Jennifer

6 years, 8 months

1
0
0 0

[PATCH v2] ipmi_si: fix use-after-free of resource->name

by Yang Yingliang

When we excute the following commands, we got oops rmmod ipmi_si cat /proc/ioports [ 1623.482380] Unable to handle kernel paging request at virtual address ffff00000901d478 [ 1623.482382] Mem abort info: [ 1623.482383] ESR = 0x96000007 [ 1623.482385] Exception class = DABT (current EL), IL = 32 bits [ 1623.482386] SET = 0, FnV = 0 [ 1623.482387] EA = 0, S1PTW = 0 [ 1623.482388] Data abort info: [ 1623.482389] ISV = 0, ISS = 0x00000007 [ 1623.482390] CM = 0, WnR = 0 [ 1623.482393] swapper pgtable: 4k pages, 48-bit VAs, pgdp = 00000000d7d94a66 [ 1623.482395] [ffff00000901d478] pgd=000000dffbfff003, pud=000000dffbffe003, pmd=0000003f5d06e003, pte=0000000000000000 [ 1623.482399] Internal error: Oops: 96000007 [#1] SMP [ 1623.487407] Modules linked in: ipmi_si(E) nls_utf8 isofs rpcrdma ib_iser ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_umad rdma_cm ib_cm dm_mirror dm_region_hash dm_log iw_cm dm_mod aes_ce_blk crypto_simd cryptd aes_ce_cipher ses ghash_ce sha2_ce enclosure sha256_arm64 sg sha1_ce hisi_sas_v2_hw hibmc_drm sbsa_gwdt hisi_sas_main ip_tables mlx5_ib ib_uverbs marvell ib_core mlx5_core ixgbe mdio hns_dsaf ipmi_devintf hns_enet_drv ipmi_msghandler hns_mdio [last unloaded: ipmi_si] [ 1623.532410] CPU: 30 PID: 11438 Comm: cat Kdump: loaded Tainted: G E 5.0.0-rc3+ #168 [ 1623.541498] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.37 11/21/2017 [ 1623.548822] pstate: a0000005 (NzCv daif -PAN -UAO) [ 1623.553684] pc : string+0x28/0x98 [ 1623.557040] lr : vsnprintf+0x368/0x5e8 [ 1623.560837] sp : ffff000013213a80 [ 1623.564191] x29: ffff000013213a80 x28: ffff00001138abb5 [ 1623.569577] x27: ffff000013213c18 x26: ffff805f67d06049 [ 1623.574963] x25: 0000000000000000 x24: ffff00001138abb5 [ 1623.580349] x23: 0000000000000fb7 x22: ffff0000117ed000 [ 1623.585734] x21: ffff000011188fd8 x20: ffff805f67d07000 [ 1623.591119] x19: ffff805f67d06061 x18: ffffffffffffffff [ 1623.596505] x17: 0000000000000200 x16: 0000000000000000 [ 1623.601890] x15: ffff0000117ed748 x14: ffff805f67d07000 [ 1623.607276] x13: ffff805f67d0605e x12: 0000000000000000 [ 1623.612661] x11: 0000000000000000 x10: 0000000000000000 [ 1623.618046] x9 : 0000000000000000 x8 : 000000000000000f [ 1623.623432] x7 : ffff805f67d06061 x6 : fffffffffffffffe [ 1623.628817] x5 : 0000000000000012 x4 : ffff00000901d478 [ 1623.634203] x3 : ffff0a00ffffff04 x2 : ffff805f67d07000 [ 1623.639588] x1 : ffff805f67d07000 x0 : ffffffffffffffff [ 1623.644974] Process cat (pid: 11438, stack limit = 0x000000008d4cbc10) [ 1623.651592] Call trace: [ 1623.654068] string+0x28/0x98 [ 1623.657071] vsnprintf+0x368/0x5e8 [ 1623.660517] seq_vprintf+0x70/0x98 [ 1623.668009] seq_printf+0x7c/0xa0 [ 1623.675530] r_show+0xc8/0xf8 [ 1623.682558] seq_read+0x330/0x440 [ 1623.689877] proc_reg_read+0x78/0xd0 [ 1623.697346] __vfs_read+0x60/0x1a0 [ 1623.704564] vfs_read+0x94/0x150 [ 1623.711339] ksys_read+0x6c/0xd8 [ 1623.717939] __arm64_sys_read+0x24/0x30 [ 1623.725077] el0_svc_common+0x120/0x148 [ 1623.732035] el0_svc_handler+0x30/0x40 [ 1623.738757] el0_svc+0x8/0xc [ 1623.744520] Code: d1000406 aa0103e2 54000149 b4000080 (39400085) [ 1623.753441] ---[ end trace f91b6a4937de9835 ]--- [ 1623.760871] Kernel panic - not syncing: Fatal exception [ 1623.768935] SMP: stopping secondary CPUs [ 1623.775718] Kernel Offset: disabled [ 1623.781998] CPU features: 0x002,21006008 [ 1623.788777] Memory Limit: none [ 1623.798329] Starting crashdump kernel... [ 1623.805202] Bye! If io_setup is called successful in try_smi_init() but try_smi_init() goes out_err before calling ipmi_register_smi(), so ipmi_unregister_smi() will not be called while removing module. It leads to the resource that allocated in io_setup() can not be freed, but the name(DEVICE_NAME) of resource is freed while removing the module. It causes use-after-free when cat /proc/ioports. Fix this by calling io_cleanup() while try_smi_init() goes to out_err and don't call release_region() if request_region() is not called to avoid error prints. Fixes: 93c303d2045b ("ipmi_si: Clean up shutdown a bit") Cc: stable(a)vger.kernel.org Reported-by: NuoHan Qiao <qiaonuohan(a)huawei.com> Suggested-by: Corey Minyard <cminyard(a)mvista.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/char/ipmi/ipmi_si_intf.c | 5 +++++ drivers/char/ipmi/ipmi_si_port_io.c | 3 +++ 2 files changed, 8 insertions(+) diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c index dc8603d..f1b9fda 100644 --- a/drivers/char/ipmi/ipmi_si_intf.c +++ b/drivers/char/ipmi/ipmi_si_intf.c @@ -2085,6 +2085,11 @@ static int try_smi_init(struct smi_info *new_smi) WARN_ON(new_smi->io.dev->init_name != NULL); out_err: + if (rv && new_smi->io.io_cleanup) { + new_smi->io.io_cleanup(&new_smi->io); + new_smi->io.io_cleanup = NULL; + } + kfree(init_name); return rv; } diff --git a/drivers/char/ipmi/ipmi_si_port_io.c b/drivers/char/ipmi/ipmi_si_port_io.c index ef6dffc..0c46a3f 100644 --- a/drivers/char/ipmi/ipmi_si_port_io.c +++ b/drivers/char/ipmi/ipmi_si_port_io.c @@ -53,6 +53,9 @@ static void port_cleanup(struct si_sm_io *io) unsigned int addr = io->addr_data; int idx; + if (io->regsize != 1 && io->regsize != 2 && io->regsize != 4) + return; + if (addr) { for (idx = 0; idx < io->io_size; idx++) release_region(addr + idx * io->regspacing, -- 1.8.3

6 years, 8 months

3
3
0 0

FAILED: patch "[PATCH] Drivers: hv: vmbus: Check for ring when getting debug info" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ba50bf1ce9a51fc97db58b96d01306aa70bc3979 Mon Sep 17 00:00:00 2001 From: Dexuan Cui <decui(a)microsoft.com> Date: Mon, 17 Dec 2018 20:16:09 +0000 Subject: [PATCH] Drivers: hv: vmbus: Check for ring when getting debug info fc96df16a1ce is good and can already fix the "return stack garbage" issue, but let's also improve hv_ringbuffer_get_debuginfo(), which would silently return stack garbage, if people forget to check channel->state or ring_info->ring_buffer, when using the function in the future. Having an error check in the function would eliminate the potential risk. Add a Fixes tag to indicate the patch depdendency. Fixes: fc96df16a1ce ("Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels") Cc: stable(a)vger.kernel.org Cc: K. Y. Srinivasan <kys(a)microsoft.com> Cc: Haiyang Zhang <haiyangz(a)microsoft.com> Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index 64d0c85d5161..1f1a55e07733 100644 --- a/drivers/hv/ring_buffer.c +++ b/drivers/hv/ring_buffer.c @@ -164,26 +164,25 @@ hv_get_ringbuffer_availbytes(const struct hv_ring_buffer_info *rbi, } /* Get various debug metrics for the specified ring buffer. */ -void hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info *ring_info, - struct hv_ring_buffer_debug_info *debug_info) +int hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info *ring_info, + struct hv_ring_buffer_debug_info *debug_info) { u32 bytes_avail_towrite; u32 bytes_avail_toread; - if (ring_info->ring_buffer) { - hv_get_ringbuffer_availbytes(ring_info, - &bytes_avail_toread, - &bytes_avail_towrite); - - debug_info->bytes_avail_toread = bytes_avail_toread; - debug_info->bytes_avail_towrite = bytes_avail_towrite; - debug_info->current_read_index = - ring_info->ring_buffer->read_index; - debug_info->current_write_index = - ring_info->ring_buffer->write_index; - debug_info->current_interrupt_mask = - ring_info->ring_buffer->interrupt_mask; - } + if (!ring_info->ring_buffer) + return -EINVAL; + + hv_get_ringbuffer_availbytes(ring_info, + &bytes_avail_toread, + &bytes_avail_towrite); + debug_info->bytes_avail_toread = bytes_avail_toread; + debug_info->bytes_avail_towrite = bytes_avail_towrite; + debug_info->current_read_index = ring_info->ring_buffer->read_index; + debug_info->current_write_index = ring_info->ring_buffer->write_index; + debug_info->current_interrupt_mask + = ring_info->ring_buffer->interrupt_mask; + return 0; } EXPORT_SYMBOL_GPL(hv_ringbuffer_get_debuginfo); diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index d0ff65675292..403fee01572c 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -313,12 +313,16 @@ static ssize_t out_intr_mask_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", outbound.current_interrupt_mask); } static DEVICE_ATTR_RO(out_intr_mask); @@ -328,12 +332,15 @@ static ssize_t out_read_index_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; return sprintf(buf, "%d\n", outbound.current_read_index); } static DEVICE_ATTR_RO(out_read_index); @@ -344,12 +351,15 @@ static ssize_t out_write_index_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; return sprintf(buf, "%d\n", outbound.current_write_index); } static DEVICE_ATTR_RO(out_write_index); @@ -360,12 +370,15 @@ static ssize_t out_read_bytes_avail_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; return sprintf(buf, "%d\n", outbound.bytes_avail_toread); } static DEVICE_ATTR_RO(out_read_bytes_avail); @@ -376,12 +389,15 @@ static ssize_t out_write_bytes_avail_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; return sprintf(buf, "%d\n", outbound.bytes_avail_towrite); } static DEVICE_ATTR_RO(out_write_bytes_avail); @@ -391,12 +407,15 @@ static ssize_t in_intr_mask_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.current_interrupt_mask); } static DEVICE_ATTR_RO(in_intr_mask); @@ -406,12 +425,15 @@ static ssize_t in_read_index_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.current_read_index); } static DEVICE_ATTR_RO(in_read_index); @@ -421,12 +443,15 @@ static ssize_t in_write_index_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.current_write_index); } static DEVICE_ATTR_RO(in_write_index); @@ -437,12 +462,15 @@ static ssize_t in_read_bytes_avail_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.bytes_avail_toread); } static DEVICE_ATTR_RO(in_read_bytes_avail); @@ -453,12 +481,15 @@ static ssize_t in_write_bytes_avail_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.bytes_avail_towrite); } static DEVICE_ATTR_RO(in_write_bytes_avail); diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h index f0885cc01db6..dcb6977afce9 100644 --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -1159,8 +1159,9 @@ struct hv_ring_buffer_debug_info { u32 bytes_avail_towrite; }; -void hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info *ring_info, - struct hv_ring_buffer_debug_info *debug_info); + +int hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info *ring_info, + struct hv_ring_buffer_debug_info *debug_info); /* Vmbus interface */ #define vmbus_driver_register(driver) \

6 years, 8 months

2
1
0 0

FAILED: patch "[PATCH] Drivers: hv: vmbus: Check for ring when getting debug info" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ba50bf1ce9a51fc97db58b96d01306aa70bc3979 Mon Sep 17 00:00:00 2001 From: Dexuan Cui <decui(a)microsoft.com> Date: Mon, 17 Dec 2018 20:16:09 +0000 Subject: [PATCH] Drivers: hv: vmbus: Check for ring when getting debug info fc96df16a1ce is good and can already fix the "return stack garbage" issue, but let's also improve hv_ringbuffer_get_debuginfo(), which would silently return stack garbage, if people forget to check channel->state or ring_info->ring_buffer, when using the function in the future. Having an error check in the function would eliminate the potential risk. Add a Fixes tag to indicate the patch depdendency. Fixes: fc96df16a1ce ("Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels") Cc: stable(a)vger.kernel.org Cc: K. Y. Srinivasan <kys(a)microsoft.com> Cc: Haiyang Zhang <haiyangz(a)microsoft.com> Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index 64d0c85d5161..1f1a55e07733 100644 --- a/drivers/hv/ring_buffer.c +++ b/drivers/hv/ring_buffer.c @@ -164,26 +164,25 @@ hv_get_ringbuffer_availbytes(const struct hv_ring_buffer_info *rbi, } /* Get various debug metrics for the specified ring buffer. */ -void hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info *ring_info, - struct hv_ring_buffer_debug_info *debug_info) +int hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info *ring_info, + struct hv_ring_buffer_debug_info *debug_info) { u32 bytes_avail_towrite; u32 bytes_avail_toread; - if (ring_info->ring_buffer) { - hv_get_ringbuffer_availbytes(ring_info, - &bytes_avail_toread, - &bytes_avail_towrite); - - debug_info->bytes_avail_toread = bytes_avail_toread; - debug_info->bytes_avail_towrite = bytes_avail_towrite; - debug_info->current_read_index = - ring_info->ring_buffer->read_index; - debug_info->current_write_index = - ring_info->ring_buffer->write_index; - debug_info->current_interrupt_mask = - ring_info->ring_buffer->interrupt_mask; - } + if (!ring_info->ring_buffer) + return -EINVAL; + + hv_get_ringbuffer_availbytes(ring_info, + &bytes_avail_toread, + &bytes_avail_towrite); + debug_info->bytes_avail_toread = bytes_avail_toread; + debug_info->bytes_avail_towrite = bytes_avail_towrite; + debug_info->current_read_index = ring_info->ring_buffer->read_index; + debug_info->current_write_index = ring_info->ring_buffer->write_index; + debug_info->current_interrupt_mask + = ring_info->ring_buffer->interrupt_mask; + return 0; } EXPORT_SYMBOL_GPL(hv_ringbuffer_get_debuginfo); diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index d0ff65675292..403fee01572c 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -313,12 +313,16 @@ static ssize_t out_intr_mask_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", outbound.current_interrupt_mask); } static DEVICE_ATTR_RO(out_intr_mask); @@ -328,12 +332,15 @@ static ssize_t out_read_index_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; return sprintf(buf, "%d\n", outbound.current_read_index); } static DEVICE_ATTR_RO(out_read_index); @@ -344,12 +351,15 @@ static ssize_t out_write_index_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; return sprintf(buf, "%d\n", outbound.current_write_index); } static DEVICE_ATTR_RO(out_write_index); @@ -360,12 +370,15 @@ static ssize_t out_read_bytes_avail_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; return sprintf(buf, "%d\n", outbound.bytes_avail_toread); } static DEVICE_ATTR_RO(out_read_bytes_avail); @@ -376,12 +389,15 @@ static ssize_t out_write_bytes_avail_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info outbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, &outbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->outbound, + &outbound); + if (ret < 0) + return ret; return sprintf(buf, "%d\n", outbound.bytes_avail_towrite); } static DEVICE_ATTR_RO(out_write_bytes_avail); @@ -391,12 +407,15 @@ static ssize_t in_intr_mask_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.current_interrupt_mask); } static DEVICE_ATTR_RO(in_intr_mask); @@ -406,12 +425,15 @@ static ssize_t in_read_index_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.current_read_index); } static DEVICE_ATTR_RO(in_read_index); @@ -421,12 +443,15 @@ static ssize_t in_write_index_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.current_write_index); } static DEVICE_ATTR_RO(in_write_index); @@ -437,12 +462,15 @@ static ssize_t in_read_bytes_avail_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.bytes_avail_toread); } static DEVICE_ATTR_RO(in_read_bytes_avail); @@ -453,12 +481,15 @@ static ssize_t in_write_bytes_avail_show(struct device *dev, { struct hv_device *hv_dev = device_to_hv_device(dev); struct hv_ring_buffer_debug_info inbound; + int ret; if (!hv_dev->channel) return -ENODEV; - if (hv_dev->channel->state != CHANNEL_OPENED_STATE) - return -EINVAL; - hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + + ret = hv_ringbuffer_get_debuginfo(&hv_dev->channel->inbound, &inbound); + if (ret < 0) + return ret; + return sprintf(buf, "%d\n", inbound.bytes_avail_towrite); } static DEVICE_ATTR_RO(in_write_bytes_avail); diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h index f0885cc01db6..dcb6977afce9 100644 --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -1159,8 +1159,9 @@ struct hv_ring_buffer_debug_info { u32 bytes_avail_towrite; }; -void hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info *ring_info, - struct hv_ring_buffer_debug_info *debug_info); + +int hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info *ring_info, + struct hv_ring_buffer_debug_info *debug_info); /* Vmbus interface */ #define vmbus_driver_register(driver) \

6 years, 8 months

2
1
0 0

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 9f1a389a0b5b Linux 4.20.5 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 9f1a389a0b5b Linux 4.20.5 We then merged the following patches with `git am`: amd-xgbe-fix-mdio-access-for-non-zero-ports-and-clause-45-phys.patch net-bridge-fix-ethernet-header-pointer-before-check-skb-forwardable.patch net-fix-usage-of-pskb_trim_rcsum.patch net-phy-marvell-errata-for-mv88e6390-internal-phys.patch net-phy-mdio_bus-add-missing-device_del-in-mdiobus_register-error-handling.patch net-phy-phy-driver-features-are-mandatory.patch net-sched-act_tunnel_key-fix-memory-leak-in-case-of-action-replace.patch net_sched-refetch-skb-protocol-for-each-filter.patch openvswitch-avoid-oob-read-when-parsing-flow-nlattrs.patch vhost-log-dirty-page-correctly.patch mlxsw-pci-increase-pci-sw-reset-timeout.patch net-ipv4-fix-memory-leak-in-network-namespace-dismantle.patch mlxsw-spectrum_fid-update-dummy-fid-index.patch mlxsw-pci-ring-cq-s-doorbell-before-rdq-s.patch net-sched-cls_flower-allocate-mask-dynamically-in-fl_change.patch udp-with-udp_segment-release-on-error-path.patch ip6_gre-fix-tunnel-list-corruption-for-x-netns.patch erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch net-phy-marvell-fix-deadlock-from-wrong-locking.patch ip6_gre-update-version-related-info-when-changing-link.patch tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch arm-fix-the-cockup-in-the-previous-patch.patch sunrpc-address-kerberos-performance-behavior-regress.patch mei-me-mark-lbg-devices-as-having-dma-support.patch mei-me-add-denverton-innovation-engine-device-ids.patch usb-leds-fix-regression-in-usbport-led-trigger.patch usb-ehci-ehci-mv-add-module_device_table.patch usb-serial-ftdi_sio-fix-gpio-not-working-in-autosuspend.patch usb-serial-simple-add-motorola-tetra-tpg2200-device-id.patch usb-serial-pl2303-add-new-pid-to-support-pl2303tb.patch ceph-clear-inode-pointer-when-snap-realm-gets-dropped-by-its-inode.patch asoc-atom-fix-a-missing-check-of-snd_pcm_lib_malloc_pages.patch asoc-rt5514-spi-fix-potential-null-pointer-dereference.patch asoc-tlv320aic32x4-kernel-oops-while-entering-dapm-standby-mode.patch clk-zynqmp-fix-memory-allocation-in-zynqmp_clk_setup.patch clk-socfpga-stratix10-fix-rate-calculation-for-pll-clocks.patch clk-socfpga-stratix10-fix-naming-convention-for-the-fixed-clocks.patch inotify-fix-fd-refcount-leak-in-inotify_add_watch.patch alsa-hda-realtek-fix-typo-for-alc225-model.patch alsa-hda-add-mute-led-support-for-hp-probook-470-g5.patch arcv2-lib-memeset-fix-doing-prefetchw-outside-of-buffer.patch arc-adjust-memblock_reserve-of-kernel-memory.patch arc-perf-map-generic-branches-to-correct-hardware-condition.patch s390-vdso-correct-vdso-mapping-for-compat-tasks.patch s390-mm-always-force-a-load-of-the-primary-asce-on-context-switch.patch s390-early-improve-machine-detection.patch s390-smp-fix-cpu-hotplug-deadlock-with-cpu-rescan.patch s390-smp-fix-calling-smp_call_ipl_cpu-from-ipl-cpu.patch misc-ibmvsm-fix-potential-null-pointer-dereference.patch char-mwave-fix-potential-spectre-v1-vulnerability.patch mmc-sdhci-iproc-handle-mmc_of_parse-errors-during-probe.patch mmc-dw_mmc-bluefield-fix-the-license-information.patch mmc-meson-gx-free-irq-in-release-callback.patch staging-rtl8188eu-add-device-code-for-d-link-dwa-121-rev-b1.patch tty-handle-problem-if-line-discipline-does-not-have-receive_buf.patch uart-fix-crash-in-uart_write-and-uart_put_char.patch tty-n_hdlc-fix-__might_sleep-warning.patch hv_balloon-avoid-touching-uninitialized-struct-page-during-tail-onlining.patch drivers-hv-vmbus-check-for-ring-when-getting-debug-info.patch vgacon-unconfuse-vc_origin-when-using-soft-scrollback.patch Compile testing --------------- We compiled the kernel for 4 architectures: s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/f8ff01b00cb156ea1df3388194f8… powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/32cf81a216f4072af2a655c506… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/d797eeb09d653dafd711df4299… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/3dcb6253677bcff7082ff2794e2… Hardware testing ---------------- We booted each kernel and ran the following tests: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu powerpc: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 8 months

1
0
0 0

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 9f1a389a0b5b Linux 4.20.5 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 9f1a389a0b5b Linux 4.20.5 We then merged the following patches with `git am`: amd-xgbe-fix-mdio-access-for-non-zero-ports-and-clause-45-phys.patch net-bridge-fix-ethernet-header-pointer-before-check-skb-forwardable.patch net-fix-usage-of-pskb_trim_rcsum.patch net-phy-marvell-errata-for-mv88e6390-internal-phys.patch net-phy-mdio_bus-add-missing-device_del-in-mdiobus_register-error-handling.patch net-phy-phy-driver-features-are-mandatory.patch net-sched-act_tunnel_key-fix-memory-leak-in-case-of-action-replace.patch net_sched-refetch-skb-protocol-for-each-filter.patch openvswitch-avoid-oob-read-when-parsing-flow-nlattrs.patch vhost-log-dirty-page-correctly.patch mlxsw-pci-increase-pci-sw-reset-timeout.patch net-ipv4-fix-memory-leak-in-network-namespace-dismantle.patch mlxsw-spectrum_fid-update-dummy-fid-index.patch mlxsw-pci-ring-cq-s-doorbell-before-rdq-s.patch net-sched-cls_flower-allocate-mask-dynamically-in-fl_change.patch udp-with-udp_segment-release-on-error-path.patch ip6_gre-fix-tunnel-list-corruption-for-x-netns.patch erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch net-phy-marvell-fix-deadlock-from-wrong-locking.patch ip6_gre-update-version-related-info-when-changing-link.patch tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch arm-fix-the-cockup-in-the-previous-patch.patch sunrpc-address-kerberos-performance-behavior-regress.patch mei-me-mark-lbg-devices-as-having-dma-support.patch mei-me-add-denverton-innovation-engine-device-ids.patch usb-leds-fix-regression-in-usbport-led-trigger.patch usb-ehci-ehci-mv-add-module_device_table.patch usb-serial-ftdi_sio-fix-gpio-not-working-in-autosuspend.patch usb-serial-simple-add-motorola-tetra-tpg2200-device-id.patch usb-serial-pl2303-add-new-pid-to-support-pl2303tb.patch ceph-clear-inode-pointer-when-snap-realm-gets-dropped-by-its-inode.patch asoc-atom-fix-a-missing-check-of-snd_pcm_lib_malloc_pages.patch asoc-rt5514-spi-fix-potential-null-pointer-dereference.patch asoc-tlv320aic32x4-kernel-oops-while-entering-dapm-standby-mode.patch clk-zynqmp-fix-memory-allocation-in-zynqmp_clk_setup.patch clk-socfpga-stratix10-fix-rate-calculation-for-pll-clocks.patch clk-socfpga-stratix10-fix-naming-convention-for-the-fixed-clocks.patch inotify-fix-fd-refcount-leak-in-inotify_add_watch.patch alsa-hda-realtek-fix-typo-for-alc225-model.patch alsa-hda-add-mute-led-support-for-hp-probook-470-g5.patch arcv2-lib-memeset-fix-doing-prefetchw-outside-of-buffer.patch arc-adjust-memblock_reserve-of-kernel-memory.patch arc-perf-map-generic-branches-to-correct-hardware-condition.patch s390-vdso-correct-vdso-mapping-for-compat-tasks.patch s390-mm-always-force-a-load-of-the-primary-asce-on-context-switch.patch s390-early-improve-machine-detection.patch s390-smp-fix-cpu-hotplug-deadlock-with-cpu-rescan.patch s390-smp-fix-calling-smp_call_ipl_cpu-from-ipl-cpu.patch misc-ibmvsm-fix-potential-null-pointer-dereference.patch char-mwave-fix-potential-spectre-v1-vulnerability.patch mmc-sdhci-iproc-handle-mmc_of_parse-errors-during-probe.patch mmc-dw_mmc-bluefield-fix-the-license-information.patch mmc-meson-gx-free-irq-in-release-callback.patch staging-rtl8188eu-add-device-code-for-d-link-dwa-121-rev-b1.patch Compile testing --------------- We compiled the kernel for 4 architectures: s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/a33fdb9d9e1d131a80d39a6c2605… powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/6a6c7c8e8db48ca38c9e2f8958… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/5ed6395d0db766d3bccf1292d1… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/e3046f5d6b5fc8f75ec7cec3f09… Hardware testing ---------------- We booted each kernel and ran the following tests: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu powerpc: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 8 months

1
0
0 0

[PATCH] [stable pre-4.8] can: bcm: check timer values before ktime conversion

by Oliver Hartkopp

Kyungtae Kim detected a potential integer overflow in bcm_[rx|tx]_setup() when the conversion into ktime multiplies the given value with NSEC_PER_USEC (1000). Reference: https://marc.info/?l=linux-can&m=154732118819828&w=2 Add a check for the given tv_usec, so that the value stays below one second. Additionally limit the tv_sec value to a reasonable value for CAN related use-cases of 400 days and ensure all values to be positive. This patch is the pre-4.8 version of upstream commit 93171ba6f1deffd8 Reported-by: Kyungtae Kim <kt0755(a)gmail.com> Tested-by: Oliver Hartkopp <socketcan(a)hartkopp.net> Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net> Cc: linux-stable <stable(a)vger.kernel.org> # versions 2.6.26 to 4.7 Tested-by: Kyungtae Kim <kt0755(a)gmail.com> Acked-by: Andre Naujoks <nautsch2(a)gmail.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- net/can/bcm.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/net/can/bcm.c b/net/can/bcm.c index 6863310d6973..01d489d0a3de 100644 --- a/net/can/bcm.c +++ b/net/can/bcm.c @@ -67,6 +67,9 @@ */ #define MAX_NFRAMES 256 +/* limit timers to 400 days for sending/timeouts */ +#define BCM_TIMER_SEC_MAX (400 * 24 * 60 * 60) + /* use of last_frames[index].can_dlc */ #define RX_RECV 0x40 /* received data for this element */ #define RX_THR 0x80 /* element not been sent due to throttle feature */ @@ -136,6 +139,22 @@ static inline ktime_t bcm_timeval_to_ktime(struct bcm_timeval tv) return ktime_set(tv.tv_sec, tv.tv_usec * NSEC_PER_USEC); } +/* check limitations for timeval provided by user */ +static bool bcm_is_invalid_tv(struct bcm_msg_head *msg_head) +{ + if ((msg_head->ival1.tv_sec < 0) || + (msg_head->ival1.tv_sec > BCM_TIMER_SEC_MAX) || + (msg_head->ival1.tv_usec < 0) || + (msg_head->ival1.tv_usec >= USEC_PER_SEC) || + (msg_head->ival2.tv_sec < 0) || + (msg_head->ival2.tv_sec > BCM_TIMER_SEC_MAX) || + (msg_head->ival2.tv_usec < 0) || + (msg_head->ival2.tv_usec >= USEC_PER_SEC)) + return true; + + return false; +} + #define CFSIZ sizeof(struct can_frame) #define OPSIZ sizeof(struct bcm_op) #define MHSIZ sizeof(struct bcm_msg_head) @@ -846,6 +865,10 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg, if (msg_head->nframes < 1 || msg_head->nframes > MAX_NFRAMES) return -EINVAL; + /* check timeval limitations */ + if ((msg_head->flags & SETTIMER) && bcm_is_invalid_tv(msg_head)) + return -EINVAL; + /* check the given can_id */ op = bcm_find_op(&bo->tx_ops, msg_head->can_id, ifindex); @@ -1011,6 +1034,10 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg, (!(msg_head->can_id & CAN_RTR_FLAG)))) return -EINVAL; + /* check timeval limitations */ + if ((msg_head->flags & SETTIMER) && bcm_is_invalid_tv(msg_head)) + return -EINVAL; + /* check the given can_id */ op = bcm_find_op(&bo->rx_ops, msg_head->can_id, ifindex); if (op) { -- 2.20.1

6 years, 8 months

3
3
0 0

FAILED: patch "[PATCH] usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd6742249b9ca918565e4e3abaa06665e587f4b5 Mon Sep 17 00:00:00 2001 From: Jack Pham <jackp(a)codeaurora.org> Date: Thu, 10 Jan 2019 12:39:55 -0800 Subject: [PATCH] usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup OUT endpoint requests may somtimes have this flag set when preparing to be submitted to HW indicating that there is an additional TRB chained to the request for alignment purposes. If that request is removed before the controller can execute the transfer (e.g. ep_dequeue/ep_disable), the request will not go through the dwc3_gadget_ep_cleanup_completed_request() handler and will not have its needs_extra_trb flag cleared when dwc3_gadget_giveback() is called. This same request could be later requeued for a new transfer that does not require an extra TRB and if it is successfully completed, the cleanup and TRB reclamation will incorrectly process the additional TRB which belongs to the next request, and incorrectly advances the TRB dequeue pointer, thereby messing up calculation of the next requeust's actual/remaining count when it completes. The right thing to do here is to ensure that the flag is cleared before it is given back to the function driver. A good place to do that is in dwc3_gadget_del_and_unmap_request(). Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable(a)vger.kernel.org Signed-off-by: Jack Pham <jackp(a)codeaurora.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 851fd44d56ad..6e2b6d6369aa 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -177,6 +177,7 @@ static void dwc3_gadget_del_and_unmap_request(struct dwc3_ep *dep, req->started = false; list_del(&req->list); req->remaining = 0; + req->needs_extra_trb = false; if (req->request.status == -EINPROGRESS) req->request.status = status;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd6742249b9ca918565e4e3abaa06665e587f4b5 Mon Sep 17 00:00:00 2001 From: Jack Pham <jackp(a)codeaurora.org> Date: Thu, 10 Jan 2019 12:39:55 -0800 Subject: [PATCH] usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup OUT endpoint requests may somtimes have this flag set when preparing to be submitted to HW indicating that there is an additional TRB chained to the request for alignment purposes. If that request is removed before the controller can execute the transfer (e.g. ep_dequeue/ep_disable), the request will not go through the dwc3_gadget_ep_cleanup_completed_request() handler and will not have its needs_extra_trb flag cleared when dwc3_gadget_giveback() is called. This same request could be later requeued for a new transfer that does not require an extra TRB and if it is successfully completed, the cleanup and TRB reclamation will incorrectly process the additional TRB which belongs to the next request, and incorrectly advances the TRB dequeue pointer, thereby messing up calculation of the next requeust's actual/remaining count when it completes. The right thing to do here is to ensure that the flag is cleared before it is given back to the function driver. A good place to do that is in dwc3_gadget_del_and_unmap_request(). Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable(a)vger.kernel.org Signed-off-by: Jack Pham <jackp(a)codeaurora.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 851fd44d56ad..6e2b6d6369aa 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -177,6 +177,7 @@ static void dwc3_gadget_del_and_unmap_request(struct dwc3_ep *dep, req->started = false; list_del(&req->list); req->remaining = 0; + req->needs_extra_trb = false; if (req->request.status == -EINPROGRESS) req->request.status = status;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bd6742249b9ca918565e4e3abaa06665e587f4b5 Mon Sep 17 00:00:00 2001 From: Jack Pham <jackp(a)codeaurora.org> Date: Thu, 10 Jan 2019 12:39:55 -0800 Subject: [PATCH] usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup OUT endpoint requests may somtimes have this flag set when preparing to be submitted to HW indicating that there is an additional TRB chained to the request for alignment purposes. If that request is removed before the controller can execute the transfer (e.g. ep_dequeue/ep_disable), the request will not go through the dwc3_gadget_ep_cleanup_completed_request() handler and will not have its needs_extra_trb flag cleared when dwc3_gadget_giveback() is called. This same request could be later requeued for a new transfer that does not require an extra TRB and if it is successfully completed, the cleanup and TRB reclamation will incorrectly process the additional TRB which belongs to the next request, and incorrectly advances the TRB dequeue pointer, thereby messing up calculation of the next requeust's actual/remaining count when it completes. The right thing to do here is to ensure that the flag is cleared before it is given back to the function driver. A good place to do that is in dwc3_gadget_del_and_unmap_request(). Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable(a)vger.kernel.org Signed-off-by: Jack Pham <jackp(a)codeaurora.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 851fd44d56ad..6e2b6d6369aa 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -177,6 +177,7 @@ static void dwc3_gadget_del_and_unmap_request(struct dwc3_ep *dep, req->started = false; list_del(&req->list); req->remaining = 0; + req->needs_extra_trb = false; if (req->request.status == -EINPROGRESS) req->request.status = status;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] mmc: meson-gx: Free irq in release() callback" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bb364890323cca6e43f13e86d190ebf34a7d8cea Mon Sep 17 00:00:00 2001 From: Remi Pommarel <repk(a)triplefau.lt> Date: Fri, 11 Jan 2019 00:01:35 +0100 Subject: [PATCH] mmc: meson-gx: Free irq in release() callback Because the irq was requested through device managed resources API (devm_request_threaded_irq()) it was freed after meson_mmc_remove() completion, thus after mmc_free_host() has reclaimed meson_host memory. As this irq is IRQF_SHARED, while using CONFIG_DEBUG_SHIRQ, its handler get called by free_irq(). So meson_mmc_irq() was called after the meson_host memory reclamation and was using invalid memory. We ended up with the following scenario: device_release_driver() meson_mmc_remove() mmc_free_host() /* Freeing host memory */ ... devres_release_all() devm_irq_release() __free_irq() meson_mmc_irq() /* Uses freed memory */ To avoid this, the irq is released in meson_mmc_remove() and in mseon_mmc_probe() error path before mmc_free_host() gets called. Reported-by: Elie Roudninski <xademax(a)gmail.com> Signed-off-by: Remi Pommarel <repk(a)triplefau.lt> Cc: stable(a)vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c index c2690c1a50ff..f115d7c63ffe 100644 --- a/drivers/mmc/host/meson-gx-mmc.c +++ b/drivers/mmc/host/meson-gx-mmc.c @@ -179,6 +179,8 @@ struct meson_host { struct sd_emmc_desc *descs; dma_addr_t descs_dma_addr; + int irq; + bool vqmmc_enabled; }; @@ -1231,7 +1233,7 @@ static int meson_mmc_probe(struct platform_device *pdev) struct resource *res; struct meson_host *host; struct mmc_host *mmc; - int ret, irq; + int ret; mmc = mmc_alloc_host(sizeof(struct meson_host), &pdev->dev); if (!mmc) @@ -1276,8 +1278,8 @@ static int meson_mmc_probe(struct platform_device *pdev) goto free_host; } - irq = platform_get_irq(pdev, 0); - if (irq <= 0) { + host->irq = platform_get_irq(pdev, 0); + if (host->irq <= 0) { dev_err(&pdev->dev, "failed to get interrupt resource.\n"); ret = -EINVAL; goto free_host; @@ -1331,9 +1333,8 @@ static int meson_mmc_probe(struct platform_device *pdev) writel(IRQ_CRC_ERR | IRQ_TIMEOUTS | IRQ_END_OF_CHAIN, host->regs + SD_EMMC_IRQ_EN); - ret = devm_request_threaded_irq(&pdev->dev, irq, meson_mmc_irq, - meson_mmc_irq_thread, IRQF_SHARED, - NULL, host); + ret = request_threaded_irq(host->irq, meson_mmc_irq, + meson_mmc_irq_thread, IRQF_SHARED, NULL, host); if (ret) goto err_init_clk; @@ -1351,7 +1352,7 @@ static int meson_mmc_probe(struct platform_device *pdev) if (host->bounce_buf == NULL) { dev_err(host->dev, "Unable to map allocate DMA bounce buffer.\n"); ret = -ENOMEM; - goto err_init_clk; + goto err_free_irq; } host->descs = dma_alloc_coherent(host->dev, SD_EMMC_DESC_BUF_LEN, @@ -1370,6 +1371,8 @@ static int meson_mmc_probe(struct platform_device *pdev) err_bounce_buf: dma_free_coherent(host->dev, host->bounce_buf_size, host->bounce_buf, host->bounce_dma_addr); +err_free_irq: + free_irq(host->irq, host); err_init_clk: clk_disable_unprepare(host->mmc_clk); err_core_clk: @@ -1387,6 +1390,7 @@ static int meson_mmc_remove(struct platform_device *pdev) /* disable interrupts */ writel(0, host->regs + SD_EMMC_IRQ_EN); + free_irq(host->irq, host); dma_free_coherent(host->dev, SD_EMMC_DESC_BUF_LEN, host->descs, host->descs_dma_addr);

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] mmc: meson-gx: Free irq in release() callback" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bb364890323cca6e43f13e86d190ebf34a7d8cea Mon Sep 17 00:00:00 2001 From: Remi Pommarel <repk(a)triplefau.lt> Date: Fri, 11 Jan 2019 00:01:35 +0100 Subject: [PATCH] mmc: meson-gx: Free irq in release() callback Because the irq was requested through device managed resources API (devm_request_threaded_irq()) it was freed after meson_mmc_remove() completion, thus after mmc_free_host() has reclaimed meson_host memory. As this irq is IRQF_SHARED, while using CONFIG_DEBUG_SHIRQ, its handler get called by free_irq(). So meson_mmc_irq() was called after the meson_host memory reclamation and was using invalid memory. We ended up with the following scenario: device_release_driver() meson_mmc_remove() mmc_free_host() /* Freeing host memory */ ... devres_release_all() devm_irq_release() __free_irq() meson_mmc_irq() /* Uses freed memory */ To avoid this, the irq is released in meson_mmc_remove() and in mseon_mmc_probe() error path before mmc_free_host() gets called. Reported-by: Elie Roudninski <xademax(a)gmail.com> Signed-off-by: Remi Pommarel <repk(a)triplefau.lt> Cc: stable(a)vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c index c2690c1a50ff..f115d7c63ffe 100644 --- a/drivers/mmc/host/meson-gx-mmc.c +++ b/drivers/mmc/host/meson-gx-mmc.c @@ -179,6 +179,8 @@ struct meson_host { struct sd_emmc_desc *descs; dma_addr_t descs_dma_addr; + int irq; + bool vqmmc_enabled; }; @@ -1231,7 +1233,7 @@ static int meson_mmc_probe(struct platform_device *pdev) struct resource *res; struct meson_host *host; struct mmc_host *mmc; - int ret, irq; + int ret; mmc = mmc_alloc_host(sizeof(struct meson_host), &pdev->dev); if (!mmc) @@ -1276,8 +1278,8 @@ static int meson_mmc_probe(struct platform_device *pdev) goto free_host; } - irq = platform_get_irq(pdev, 0); - if (irq <= 0) { + host->irq = platform_get_irq(pdev, 0); + if (host->irq <= 0) { dev_err(&pdev->dev, "failed to get interrupt resource.\n"); ret = -EINVAL; goto free_host; @@ -1331,9 +1333,8 @@ static int meson_mmc_probe(struct platform_device *pdev) writel(IRQ_CRC_ERR | IRQ_TIMEOUTS | IRQ_END_OF_CHAIN, host->regs + SD_EMMC_IRQ_EN); - ret = devm_request_threaded_irq(&pdev->dev, irq, meson_mmc_irq, - meson_mmc_irq_thread, IRQF_SHARED, - NULL, host); + ret = request_threaded_irq(host->irq, meson_mmc_irq, + meson_mmc_irq_thread, IRQF_SHARED, NULL, host); if (ret) goto err_init_clk; @@ -1351,7 +1352,7 @@ static int meson_mmc_probe(struct platform_device *pdev) if (host->bounce_buf == NULL) { dev_err(host->dev, "Unable to map allocate DMA bounce buffer.\n"); ret = -ENOMEM; - goto err_init_clk; + goto err_free_irq; } host->descs = dma_alloc_coherent(host->dev, SD_EMMC_DESC_BUF_LEN, @@ -1370,6 +1371,8 @@ static int meson_mmc_probe(struct platform_device *pdev) err_bounce_buf: dma_free_coherent(host->dev, host->bounce_buf_size, host->bounce_buf, host->bounce_dma_addr); +err_free_irq: + free_irq(host->irq, host); err_init_clk: clk_disable_unprepare(host->mmc_clk); err_core_clk: @@ -1387,6 +1390,7 @@ static int meson_mmc_remove(struct platform_device *pdev) /* disable interrupts */ writel(0, host->regs + SD_EMMC_IRQ_EN); + free_irq(host->irq, host); dma_free_coherent(host->dev, SD_EMMC_DESC_BUF_LEN, host->descs, host->descs_dma_addr);

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2bd44dadd5bfb4135162322fd0b45a174d4ad5bf Mon Sep 17 00:00:00 2001 From: Stefan Wahren <stefan.wahren(a)i2se.com> Date: Sun, 23 Dec 2018 21:59:17 +0100 Subject: [PATCH] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe We need to handle mmc_of_parse() errors during probe. This finally fixes the wifi regression on Raspberry Pi 3 series. In error case the wifi chip was permanently in reset because of the power sequence depending on the deferred probe of the GPIO expander. Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Cc: stable(a)vger.kernel.org Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c index 0db99057c44f..9d12c06c7fd6 100644 --- a/drivers/mmc/host/sdhci-iproc.c +++ b/drivers/mmc/host/sdhci-iproc.c @@ -296,7 +296,10 @@ static int sdhci_iproc_probe(struct platform_device *pdev) iproc_host->data = iproc_data; - mmc_of_parse(host->mmc); + ret = mmc_of_parse(host->mmc); + if (ret) + goto err; + sdhci_get_property(pdev); host->mmc->caps |= iproc_host->data->mmc_caps;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2bd44dadd5bfb4135162322fd0b45a174d4ad5bf Mon Sep 17 00:00:00 2001 From: Stefan Wahren <stefan.wahren(a)i2se.com> Date: Sun, 23 Dec 2018 21:59:17 +0100 Subject: [PATCH] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe We need to handle mmc_of_parse() errors during probe. This finally fixes the wifi regression on Raspberry Pi 3 series. In error case the wifi chip was permanently in reset because of the power sequence depending on the deferred probe of the GPIO expander. Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Cc: stable(a)vger.kernel.org Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c index 0db99057c44f..9d12c06c7fd6 100644 --- a/drivers/mmc/host/sdhci-iproc.c +++ b/drivers/mmc/host/sdhci-iproc.c @@ -296,7 +296,10 @@ static int sdhci_iproc_probe(struct platform_device *pdev) iproc_host->data = iproc_data; - mmc_of_parse(host->mmc); + ret = mmc_of_parse(host->mmc); + if (ret) + goto err; + sdhci_get_property(pdev); host->mmc->caps |= iproc_host->data->mmc_caps;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2bd44dadd5bfb4135162322fd0b45a174d4ad5bf Mon Sep 17 00:00:00 2001 From: Stefan Wahren <stefan.wahren(a)i2se.com> Date: Sun, 23 Dec 2018 21:59:17 +0100 Subject: [PATCH] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe We need to handle mmc_of_parse() errors during probe. This finally fixes the wifi regression on Raspberry Pi 3 series. In error case the wifi chip was permanently in reset because of the power sequence depending on the deferred probe of the GPIO expander. Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Cc: stable(a)vger.kernel.org Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c index 0db99057c44f..9d12c06c7fd6 100644 --- a/drivers/mmc/host/sdhci-iproc.c +++ b/drivers/mmc/host/sdhci-iproc.c @@ -296,7 +296,10 @@ static int sdhci_iproc_probe(struct platform_device *pdev) iproc_host->data = iproc_data; - mmc_of_parse(host->mmc); + ret = mmc_of_parse(host->mmc); + if (ret) + goto err; + sdhci_get_property(pdev); host->mmc->caps |= iproc_host->data->mmc_caps;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2bd44dadd5bfb4135162322fd0b45a174d4ad5bf Mon Sep 17 00:00:00 2001 From: Stefan Wahren <stefan.wahren(a)i2se.com> Date: Sun, 23 Dec 2018 21:59:17 +0100 Subject: [PATCH] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe We need to handle mmc_of_parse() errors during probe. This finally fixes the wifi regression on Raspberry Pi 3 series. In error case the wifi chip was permanently in reset because of the power sequence depending on the deferred probe of the GPIO expander. Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Cc: stable(a)vger.kernel.org Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c index 0db99057c44f..9d12c06c7fd6 100644 --- a/drivers/mmc/host/sdhci-iproc.c +++ b/drivers/mmc/host/sdhci-iproc.c @@ -296,7 +296,10 @@ static int sdhci_iproc_probe(struct platform_device *pdev) iproc_host->data = iproc_data; - mmc_of_parse(host->mmc); + ret = mmc_of_parse(host->mmc); + if (ret) + goto err; + sdhci_get_property(pdev); host->mmc->caps |= iproc_host->data->mmc_caps;

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] s390/mm: always force a load of the primary ASCE on context" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a38662084c8bdb829ff486468c7ea801c13fcc34 Mon Sep 17 00:00:00 2001 From: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Date: Tue, 8 Jan 2019 12:44:57 +0100 Subject: [PATCH] s390/mm: always force a load of the primary ASCE on context switch The ASCE of an mm_struct can be modified after a task has been created, e.g. via crst_table_downgrade for a compat process. The active_mm logic to avoid the switch_mm call if the next task is a kernel thread can lead to a situation where switch_mm is called where 'prev == next' is true but 'prev->context.asce == next->context.asce' is not. This can lead to a situation where a CPU uses the outdated ASCE to run a task. The result can be a crash, endless loops and really subtle problem due to TLBs being created with an invalid ASCE. Cc: stable(a)kernel.org # v3.15+ Fixes: 53e857f30867 ("s390/mm,tlb: race of lazy TLB flush vs. recreation") Reported-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h index ccbb53e22024..e4462202200d 100644 --- a/arch/s390/include/asm/mmu_context.h +++ b/arch/s390/include/asm/mmu_context.h @@ -90,8 +90,6 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, { int cpu = smp_processor_id(); - if (prev == next) - return; S390_lowcore.user_asce = next->context.asce; cpumask_set_cpu(cpu, &next->context.cpu_attach_mask); /* Clear previous user-ASCE from CR1 and CR7 */ @@ -103,7 +101,8 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, __ctl_load(S390_lowcore.vdso_asce, 7, 7); clear_cpu_flag(CIF_ASCE_SECONDARY); } - cpumask_clear_cpu(cpu, &prev->context.cpu_attach_mask); + if (prev != next) + cpumask_clear_cpu(cpu, &prev->context.cpu_attach_mask); } #define finish_arch_post_lock_switch finish_arch_post_lock_switch

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] s390/mm: always force a load of the primary ASCE on context" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a38662084c8bdb829ff486468c7ea801c13fcc34 Mon Sep 17 00:00:00 2001 From: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Date: Tue, 8 Jan 2019 12:44:57 +0100 Subject: [PATCH] s390/mm: always force a load of the primary ASCE on context switch The ASCE of an mm_struct can be modified after a task has been created, e.g. via crst_table_downgrade for a compat process. The active_mm logic to avoid the switch_mm call if the next task is a kernel thread can lead to a situation where switch_mm is called where 'prev == next' is true but 'prev->context.asce == next->context.asce' is not. This can lead to a situation where a CPU uses the outdated ASCE to run a task. The result can be a crash, endless loops and really subtle problem due to TLBs being created with an invalid ASCE. Cc: stable(a)kernel.org # v3.15+ Fixes: 53e857f30867 ("s390/mm,tlb: race of lazy TLB flush vs. recreation") Reported-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h index ccbb53e22024..e4462202200d 100644 --- a/arch/s390/include/asm/mmu_context.h +++ b/arch/s390/include/asm/mmu_context.h @@ -90,8 +90,6 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, { int cpu = smp_processor_id(); - if (prev == next) - return; S390_lowcore.user_asce = next->context.asce; cpumask_set_cpu(cpu, &next->context.cpu_attach_mask); /* Clear previous user-ASCE from CR1 and CR7 */ @@ -103,7 +101,8 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, __ctl_load(S390_lowcore.vdso_asce, 7, 7); clear_cpu_flag(CIF_ASCE_SECONDARY); } - cpumask_clear_cpu(cpu, &prev->context.cpu_attach_mask); + if (prev != next) + cpumask_clear_cpu(cpu, &prev->context.cpu_attach_mask); } #define finish_arch_post_lock_switch finish_arch_post_lock_switch

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] s390/mm: always force a load of the primary ASCE on context" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a38662084c8bdb829ff486468c7ea801c13fcc34 Mon Sep 17 00:00:00 2001 From: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Date: Tue, 8 Jan 2019 12:44:57 +0100 Subject: [PATCH] s390/mm: always force a load of the primary ASCE on context switch The ASCE of an mm_struct can be modified after a task has been created, e.g. via crst_table_downgrade for a compat process. The active_mm logic to avoid the switch_mm call if the next task is a kernel thread can lead to a situation where switch_mm is called where 'prev == next' is true but 'prev->context.asce == next->context.asce' is not. This can lead to a situation where a CPU uses the outdated ASCE to run a task. The result can be a crash, endless loops and really subtle problem due to TLBs being created with an invalid ASCE. Cc: stable(a)kernel.org # v3.15+ Fixes: 53e857f30867 ("s390/mm,tlb: race of lazy TLB flush vs. recreation") Reported-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h index ccbb53e22024..e4462202200d 100644 --- a/arch/s390/include/asm/mmu_context.h +++ b/arch/s390/include/asm/mmu_context.h @@ -90,8 +90,6 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, { int cpu = smp_processor_id(); - if (prev == next) - return; S390_lowcore.user_asce = next->context.asce; cpumask_set_cpu(cpu, &next->context.cpu_attach_mask); /* Clear previous user-ASCE from CR1 and CR7 */ @@ -103,7 +101,8 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, __ctl_load(S390_lowcore.vdso_asce, 7, 7); clear_cpu_flag(CIF_ASCE_SECONDARY); } - cpumask_clear_cpu(cpu, &prev->context.cpu_attach_mask); + if (prev != next) + cpumask_clear_cpu(cpu, &prev->context.cpu_attach_mask); } #define finish_arch_post_lock_switch finish_arch_post_lock_switch

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] s390/mm: always force a load of the primary ASCE on context" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a38662084c8bdb829ff486468c7ea801c13fcc34 Mon Sep 17 00:00:00 2001 From: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Date: Tue, 8 Jan 2019 12:44:57 +0100 Subject: [PATCH] s390/mm: always force a load of the primary ASCE on context switch The ASCE of an mm_struct can be modified after a task has been created, e.g. via crst_table_downgrade for a compat process. The active_mm logic to avoid the switch_mm call if the next task is a kernel thread can lead to a situation where switch_mm is called where 'prev == next' is true but 'prev->context.asce == next->context.asce' is not. This can lead to a situation where a CPU uses the outdated ASCE to run a task. The result can be a crash, endless loops and really subtle problem due to TLBs being created with an invalid ASCE. Cc: stable(a)kernel.org # v3.15+ Fixes: 53e857f30867 ("s390/mm,tlb: race of lazy TLB flush vs. recreation") Reported-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> diff --git a/arch/s390/include/asm/mmu_context.h b/arch/s390/include/asm/mmu_context.h index ccbb53e22024..e4462202200d 100644 --- a/arch/s390/include/asm/mmu_context.h +++ b/arch/s390/include/asm/mmu_context.h @@ -90,8 +90,6 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, { int cpu = smp_processor_id(); - if (prev == next) - return; S390_lowcore.user_asce = next->context.asce; cpumask_set_cpu(cpu, &next->context.cpu_attach_mask); /* Clear previous user-ASCE from CR1 and CR7 */ @@ -103,7 +101,8 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, __ctl_load(S390_lowcore.vdso_asce, 7, 7); clear_cpu_flag(CIF_ASCE_SECONDARY); } - cpumask_clear_cpu(cpu, &prev->context.cpu_attach_mask); + if (prev != next) + cpumask_clear_cpu(cpu, &prev->context.cpu_attach_mask); } #define finish_arch_post_lock_switch finish_arch_post_lock_switch

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 4d447455e73b47c43dd35fcc38ed823d3182a474 Mon Sep 17 00:00:00 2001 From: Vineet Gupta <vgupta(a)synopsys.com> Date: Mon, 10 Dec 2018 16:56:45 -0800 Subject: [PATCH] ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if signal arrives while handle_mm_fault do_page_fault() forgot to relinquish mmap_sem if a signal came while handling handle_mm_fault() - due to say a ctl+c or oom etc. This would later cause a deadlock by acquiring it twice. This came to light when running libc testsuite tst-tls3-malloc test but is likely also the cause for prior seen LTP failures. Using lockdep clearly showed what the issue was. | # while true; do ./tst-tls3-malloc ; done | Didn't expect signal from child: got `Segmentation fault' | ^C | ============================================ | WARNING: possible recursive locking detected | 4.17.0+ #25 Not tainted | -------------------------------------------- | tst-tls3-malloc/510 is trying to acquire lock: | 606c7728 (&mm->mmap_sem){++++}, at: __might_fault+0x28/0x5c | |but task is already holding lock: |606c7728 (&mm->mmap_sem){++++}, at: do_page_fault+0x9c/0x2a0 | | other info that might help us debug this: | Possible unsafe locking scenario: | | CPU0 | ---- | lock(&mm->mmap_sem); | lock(&mm->mmap_sem); | | *** DEADLOCK *** | ------------------------------------------------------------ What the change does is not obvious (note to myself) prior code was | do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_ERROR | up_read | if user_mode | return <-- lock still held, this was the BUG New code | do_page_fault | | down_read() <-- lock taken | handle_mm_fault <-- signal pending as this runs | if fatal_signal_pending | if VM_FAULT_RETRY | return <-- not same case as above, but still OK since | core mm already relinq lock for FAULT_RETRY | ... | | < Now falls through for bug case above > | | up_read() <-- lock relinquished Cc: stable(a)vger.kernel.org Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c index a1d723197084..8df1638259f3 100644 --- a/arch/arc/mm/fault.c +++ b/arch/arc/mm/fault.c @@ -141,12 +141,17 @@ void do_page_fault(unsigned long address, struct pt_regs *regs) */ fault = handle_mm_fault(vma, address, flags); - /* If Pagefault was interrupted by SIGKILL, exit page fault "early" */ if (fatal_signal_pending(current)) { - if ((fault & VM_FAULT_ERROR) && !(fault & VM_FAULT_RETRY)) - up_read(&mm->mmap_sem); - if (user_mode(regs)) + + /* + * if fault retry, mmap_sem already relinquished by core mm + * so OK to return to user mode (with signal handled first) + */ + if (fault & VM_FAULT_RETRY) { + if (!user_mode(regs)) + goto no_context; return; + } } perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ARC: show_regs: lockdep: re-enable preemption" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From f731a8e89f8c78985707c626680f3e24c7a60772 Mon Sep 17 00:00:00 2001 From: Vineet Gupta <vgupta(a)synopsys.com> Date: Tue, 18 Dec 2018 10:39:58 -0800 Subject: [PATCH] ARC: show_regs: lockdep: re-enable preemption signal handling core calls show_regs() with preemption disabled which on ARC takes mmap_sem for mm/vma access, causing lockdep splat. | [ARCLinux]# ./segv-null-ptr | potentially unexpected fatal signal 11. | BUG: sleeping function called from invalid context at kernel/fork.c:1011 | in_atomic(): 1, irqs_disabled(): 0, pid: 70, name: segv-null-ptr | no locks held by segv-null-ptr/70. | CPU: 0 PID: 70 Comm: segv-null-ptr Not tainted 4.18.0+ #69 | | Stack Trace: | arc_unwind_core+0xcc/0x100 | ___might_sleep+0x17a/0x190 | mmput+0x16/0xb8 | show_regs+0x52/0x310 | get_signal+0x5ee/0x610 | do_signal+0x2c/0x218 | resume_user_mode_begin+0x90/0xd8 Workaround by re-enabling preemption temporarily. Note that the preemption disabling in core code around show_regs() was introduced by commit 3a9f84d354ce ("signals, debug: fix BUG: using smp_processor_id() in preemptible code in print_fatal_signal()") to silence a differnt lockdep seen on x86 bakc in 2009. Cc: <stable(a)vger.kernel.org> Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c index 5c6663321e87..215f515442e0 100644 --- a/arch/arc/kernel/troubleshoot.c +++ b/arch/arc/kernel/troubleshoot.c @@ -179,6 +179,12 @@ void show_regs(struct pt_regs *regs) struct task_struct *tsk = current; struct callee_regs *cregs; + /* + * generic code calls us with preemption disabled, but some calls + * here could sleep, so re-enable to avoid lockdep splat + */ + preempt_enable(); + print_task_path_n_nm(tsk); show_regs_print_info(KERN_INFO); @@ -221,6 +227,8 @@ void show_regs(struct pt_regs *regs) cregs = (struct callee_regs *)current->thread.callee_reg; if (cregs) show_callee_regs(cregs); + + preempt_disable(); } void show_kernel_fault_diag(const char *str, struct pt_regs *regs,

6 years, 8 months

1
0
0 0

FAILED: patch "[PATCH] ARCv2: lib: memeset: fix doing prefetchw outside of buffer" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From e6a72b7daeeb521753803550f0ed711152bb2555 Mon Sep 17 00:00:00 2001 From: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Date: Mon, 14 Jan 2019 18:16:48 +0300 Subject: [PATCH] ARCv2: lib: memeset: fix doing prefetchw outside of buffer ARCv2 optimized memset uses PREFETCHW instruction for prefetching the next cache line but doesn't ensure that the line is not past the end of the buffer. PRETECHW changes the line ownership and marks it dirty, which can cause issues in SMP config when next line was already owned by other core. Fix the issue by avoiding the PREFETCHW Some more details: The current code has 3 logical loops (ignroing the unaligned part) (a) Big loop for doing aligned 64 bytes per iteration with PREALLOC (b) Loop for 32 x 2 bytes with PREFETCHW (c) any left over bytes loop (a) was already eliding the last 64 bytes, so PREALLOC was safe. The fix was removing PREFETCW from (b). Another potential issue (applicable to configs with 32 or 128 byte L1 cache line) is that PREALLOC assumes 64 byte cache line and may not do the right thing specially for 32b. While it would be easy to adapt, there are no known configs with those lie sizes, so for now, just compile out PREALLOC in such cases. Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Cc: stable(a)vger.kernel.org #4.4+ Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> [vgupta: rewrote changelog, used asm .macro vs. "C" macro] diff --git a/arch/arc/lib/memset-archs.S b/arch/arc/lib/memset-archs.S index 62ad4bcb841a..f230bb7092fd 100644 --- a/arch/arc/lib/memset-archs.S +++ b/arch/arc/lib/memset-archs.S @@ -7,11 +7,39 @@ */ #include <linux/linkage.h> +#include <asm/cache.h> -#undef PREALLOC_NOT_AVAIL +/* + * The memset implementation below is optimized to use prefetchw and prealloc + * instruction in case of CPU with 64B L1 data cache line (L1_CACHE_SHIFT == 6) + * If you want to implement optimized memset for other possible L1 data cache + * line lengths (32B and 128B) you should rewrite code carefully checking + * we don't call any prefetchw/prealloc instruction for L1 cache lines which + * don't belongs to memset area. + */ + +#if L1_CACHE_SHIFT == 6 + +.macro PREALLOC_INSTR reg, off + prealloc [\reg, \off] +.endm + +.macro PREFETCHW_INSTR reg, off + prefetchw [\reg, \off] +.endm + +#else + +.macro PREALLOC_INSTR +.endm + +.macro PREFETCHW_INSTR +.endm + +#endif ENTRY_CFI(memset) - prefetchw [r0] ; Prefetch the write location + PREFETCHW_INSTR r0, 0 ; Prefetch the first write location mov.f 0, r2 ;;; if size is zero jz.d [blink] @@ -48,11 +76,8 @@ ENTRY_CFI(memset) lpnz @.Lset64bytes ;; LOOP START -#ifdef PREALLOC_NOT_AVAIL - prefetchw [r3, 64] ;Prefetch the next write location -#else - prealloc [r3, 64] -#endif + PREALLOC_INSTR r3, 64 ; alloc next line w/o fetching + #ifdef CONFIG_ARC_HAS_LL64 std.ab r4, [r3, 8] std.ab r4, [r3, 8] @@ -85,7 +110,6 @@ ENTRY_CFI(memset) lsr.f lp_count, r2, 5 ;Last remaining max 124 bytes lpnz .Lset32bytes ;; LOOP START - prefetchw [r3, 32] ;Prefetch the next write location #ifdef CONFIG_ARC_HAS_LL64 std.ab r4, [r3, 8] std.ab r4, [r3, 8]

6 years, 8 months

1
0
0 0

v4.20.5 build: 0 failures 4 warnings (v4.20.5)

by Build bot for Mark Brown

Tree/Branch: v4.20.5 Git describe: v4.20.5 Commit: 9f1a389a0b Linux 4.20.5 Build Time: 130 min 15 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 4 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : arm64-allmodconfig 3 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Warnings Summary: 4 1 ../drivers/staging/erofs/unzip_vle.c:188:29: warning: array subscript is above array bounds [-Warray-bounds] 1 ../drivers/scsi/myrs.c:821:24: warning: 'sshdr.sense_key' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] 1 ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 3 warnings, 0 section mismatches Warnings: ../drivers/net/ethernet/mellanox/mlx5/core/en_stats.c:216:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] ../drivers/staging/erofs/unzip_vle.c:188:29: warning: array subscript is above array bounds [-Warray-bounds] ../drivers/scsi/myrs.c:821:24: warning: 'sshdr.sense_key' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig x86_64-allmodconfig arm64-defconfig

6 years, 8 months

1
0
0 0

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 9f1a389a0b5b Linux 4.20.5 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 9f1a389a0b5b Linux 4.20.5 We then merged the following patches with `git am`: amd-xgbe-fix-mdio-access-for-non-zero-ports-and-clause-45-phys.patch net-bridge-fix-ethernet-header-pointer-before-check-skb-forwardable.patch net-fix-usage-of-pskb_trim_rcsum.patch net-phy-marvell-errata-for-mv88e6390-internal-phys.patch net-phy-mdio_bus-add-missing-device_del-in-mdiobus_register-error-handling.patch net-phy-phy-driver-features-are-mandatory.patch net-sched-act_tunnel_key-fix-memory-leak-in-case-of-action-replace.patch net_sched-refetch-skb-protocol-for-each-filter.patch openvswitch-avoid-oob-read-when-parsing-flow-nlattrs.patch vhost-log-dirty-page-correctly.patch mlxsw-pci-increase-pci-sw-reset-timeout.patch net-ipv4-fix-memory-leak-in-network-namespace-dismantle.patch mlxsw-spectrum_fid-update-dummy-fid-index.patch mlxsw-pci-ring-cq-s-doorbell-before-rdq-s.patch net-sched-cls_flower-allocate-mask-dynamically-in-fl_change.patch udp-with-udp_segment-release-on-error-path.patch ip6_gre-fix-tunnel-list-corruption-for-x-netns.patch erspan-build-the-header-with-the-right-proto-according-to-erspan_ver.patch net-phy-marvell-fix-deadlock-from-wrong-locking.patch ip6_gre-update-version-related-info-when-changing-link.patch tcp-allow-msg_zerocopy-transmission-also-in-close_wait-state.patch arm-fix-the-cockup-in-the-previous-patch.patch sunrpc-address-kerberos-performance-behavior-regress.patch Compile testing --------------- We compiled the kernel for 4 architectures: s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/028e11ea85578d0c7bc7132468d5… powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/ec3ea1c67f971c7397dda088a8… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/656836e683c8f8bf81eb206271… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/48d980621d398141252331b80ef… Hardware testing ---------------- We booted each kernel and ran the following tests: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu powerpc: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 8 months

1
0
0 0

Re: [PATCH v2] usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup

by Jack Pham

Hi Sasha, On Wed, Jan 16, 2019 at 01:35:52PM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: c6267a51639b usb: dwc3: gadget: align transfers to wMaxPacketSize. > > The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93. > > v4.20.2: Build failed! Errors: > drivers/usb/dwc3/gadget.c:180:5: error: ‘struct dwc3_request’ has no member named ‘needs_extra_trb’ > > v4.19.15: Build failed! Errors: > drivers/usb/dwc3/gadget.c:180:5: error: ‘struct dwc3_request’ has no member named ‘needs_extra_trb’ > > v4.14.93: Build failed! Errors: > drivers/usb/dwc3/gadget.c:185:5: error: ‘struct dwc3_request’ has no member named ‘needs_extra_trb’ > > > How should we proceed with this patch? I mentioned in my "cover" message of the patch that it needs a slight rewrite for -stable since the 'needs_extra_trb' was only introduced in v5.0-rc1. Now that my patch is in Linus's tree, I can send it separately for -stable; I'll fix up the commit text slightly to refer to the variables used before v5.0. Thanks, Jack -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

6 years, 8 months

2
3
0 0

[PATCH v4.14] mmc: Kconfig: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS

by Georgi Djakov

From: Vijay Viswanath <vviswana(a)codeaurora.org> commit 99d570da309813f67e9c741edeff55bafc6c1d5e upstream. Enable CONFIG_MMC_SDHCI_IO_ACCESSORS so that SDHC controller specific register read and write APIs, if registered, can be used. Signed-off-by: Vijay Viswanath <vviswana(a)codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: Koen Vandeputte <koen.vandeputte(a)ncentric.com> Cc: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov(a)linaro.org> --- We got a report [1] that a specific platform (ipq806x) fails to build, after the following commit in the v4.14 stable kernel: 4abb6960f61c ("mmc: sdhci-msm: Disable CDR function on TX") Let's pick this patch into v4.14.y to automagically select this Kconfig dependency for platforms which have enabled the driver, but not the accessors in their kernel config. [1] https://www.spinics.net/lists/linux-mmc/msg52983.html drivers/mmc/host/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 8c15637178ff..9ed786935a30 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -429,6 +429,7 @@ config MMC_SDHCI_MSM tristate "Qualcomm SDHCI Controller Support" depends on ARCH_QCOM || (ARM && COMPILE_TEST) depends on MMC_SDHCI_PLTFM + select MMC_SDHCI_IO_ACCESSORS help This selects the Secure Digital Host Controller Interface (SDHCI) support present in Qualcomm SOCs. The controller supports

6 years, 8 months

2
1
0 0

[stable] ipfrag: really prevent allocation on netns exit

by Ben Hutchings

Please pick this commit for the 4.9 and 4.14 stable branches: commit f6f2a4a2eb92bc73671204198bb2f8ab53ff59fb Author: Paolo Abeni <pabeni(a)redhat.com> Date: Fri Jul 6 12:30:20 2018 +0200 ipfrag: really prevent allocation on netns exit It's not needed on earlier branches unless other commits are also applied. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom

6 years, 8 months

2
1
0 0

Re: Need help debugging NFS issues new to 4.20 kernel

by Schumaker, Anna

On Thu, 2019-01-24 at 19:58 +0000, Trond Myklebust wrote: > On Thu, 2019-01-24 at 11:32 -0600, Jason L Tibbitts III wrote: > > I could use some help figuring out the cause of some serious NFS > > client > > issues I'm having with the 4.20.3 kernel which I did not see under > > 4.19.15. > > > > I have a network of about 130 desktops (plus a bunch of other > > machines, > > VMs and the like) running Fedora 29 connecting to six NFS servers > > running CentOS 7.6 (with the heavily patched vendor kernel > > 3.10.0-957.1.3). All machines involved are x86_64. We use > > kerberized > > NFS4 with generally sec=krb5i. The exports are generally made with > > "(rw,async,sec=krb5i:krb5p)". > > > > Since I booted those clients into 4.20.3 I've started seeing > > processes > > getting stuck in the D state. The system itself will seem OK (except > > for the high load average) as long as I don't touch the hung NFS > > mount. > > Nothing was logged to dmesg or to the journal. So far booting back > > into > > the 4.19.15 kernel has cleared up the problem. I cannot yet > > reproduce > > this on demand; I've tried but it is probably related to some > > specific > > usage pattern. > > > > Has anyone else seen issues like this? Can anyone help me to get > > more > > useful information that might point to the problem? I still haven't > > learned how to debug NFS issues properly. And if there's a stress > > test > > tool I could easily run that might help to reproduce the issue, I'd > > be > > happy to run it. > > > > I note that 4.20.4 is out; I see one sunrpc fix which I guess could > > be > > related (sunrpc: handle ENOMEM in rpcb_getport_async) but the systems > > involved have plenty of free memory so I doubt that's it. I'll > > certainly try it anyway. > > > > Various package versions: > > kernel-4.20.3-200.fc29.x86_64 (the problematic kernel) > > kernel-4.19.15-300.fc29.x86_64 (the functional kernel) > > nfs-utils-2.3.3-1.rc2.fc29.x86_64 > > gssproxy-0.8.0-6.fc29.x86_64 > > krb5-libs-1.16.1-25.fc29.i686 > > > > Thanks in advance for any help or advice, > > > > - J< > > Commit deaa5c96c2f7 ("SUNRPC: Address Kerberos performance/behavior > regression") was supposed to be marked for stable as a fix. Chuck & > Anna? Looks like I missed that, sorry! Stable folks, can you please backport deaa5c96c2f7 ("SUNRPC: Address Kerberos performance/behavior regression") to v4.20? Thanks, Anna > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust(a)hammerspace.com > >

6 years, 8 months

2
1
0 0

[PATCH 4.20 0/1] Fix regression from arm spectre patch series

by David Long

From: "David A. Long" <dave.long(a)linaro.org> Backport upstream patch for regression introduced from spectre patch series. This was run through kernelci testing. Also the kernel was built with and without BIG_LITTLE and the symbol table was examined to verify the processor tables do not go into .rodata when BIG_LITTLE=n. Russell King (1): ARM: fix the cockup in the previous patch arch/arm/mm/proc-macros.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.17.1

6 years, 8 months

2
2
0 0

stable-rc/linux-4.4.y boot: 88 boots: 2 failed, 84 passed with 2 offline (v4.4.172)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 88 boots: 2 failed, 84 passed with 2 offline (v4.4.172) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.172/ Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.172 Git Commit: 626b008972db6e4977f6b3460400f6f4e6731081 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 41 unique boards, 20 SoC families, 12 builds out of 187 Boot Failures Detected: arm64: defconfig qcom-qdf2400: 1 failed lab arm: multi_v7_defconfig stih410-b2120: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: exynos5800-peach-pi: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

stable-rc/linux-4.14.y boot: 111 boots: 1 failed, 106 passed with 2 offline, 2 conflicts (v4.14.96)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 111 boots: 1 failed, 106 passed with 2 offline, 2 conflicts (v4.14.96) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.96/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.96 Git Commit: e6608e1f2fbd5827df9fa0da9ab1ad64f68be8d7 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 61 unique boards, 23 SoC families, 11 builds out of 197 Boot Regressions Detected: arm64: defconfig: meson-gxl-s905x-khadas-vim: lab-baylibre-seattle: failing since 1 day (last pass: v4.14.95 - first fail: v4.14.95-63-g1e16acf37196) Boot Failure Detected: arm64: defconfig rk3399-firefly: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: exynos5800-peach-pi: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm64: defconfig: meson-gxl-s905x-khadas-vim: lab-baylibre: PASS lab-baylibre-seattle: FAIL meson-gxl-s905x-libretech-cc: lab-baylibre: PASS lab-baylibre-seattle: FAIL --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

[PATCH] HID: debug: fix the ring buffer implementation

by Vladis Dronov

Ring buffer implementation in hid_debug_event() and hid_debug_events_read() is strange allowing lost or corrupted data. After commit 717adfdaf147 ("HID: debug: check length before copy_to_user()") it is possible to enter an infinite loop in hid_debug_events_read() by providing 0 as count, this locks up a system. Fix this by rewriting the ring buffer implementation with kfifo and simplify the code. This fixes CVE-2019-3819. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187 Cc: stable(a)vger.kernel.org # v4.16+ Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping") Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()") Signed-off-by: Vladis Dronov <vdronov(a)redhat.com> --- drivers/hid/hid-debug.c | 116 ++++++++++++++------------------------ include/linux/hid-debug.h | 9 ++- 2 files changed, 47 insertions(+), 78 deletions(-) diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c index c530476edba6..08870c909268 100644 --- a/drivers/hid/hid-debug.c +++ b/drivers/hid/hid-debug.c @@ -30,6 +30,7 @@ #include <linux/debugfs.h> #include <linux/seq_file.h> +#include <linux/kfifo.h> #include <linux/sched/signal.h> #include <linux/export.h> #include <linux/slab.h> @@ -661,17 +662,12 @@ EXPORT_SYMBOL_GPL(hid_dump_device); /* enqueue string to 'events' ring buffer */ void hid_debug_event(struct hid_device *hdev, char *buf) { - unsigned i; struct hid_debug_list *list; unsigned long flags; spin_lock_irqsave(&hdev->debug_list_lock, flags); - list_for_each_entry(list, &hdev->debug_list, node) { - for (i = 0; buf[i]; i++) - list->hid_debug_buf[(list->tail + i) % HID_DEBUG_BUFSIZE] = - buf[i]; - list->tail = (list->tail + i) % HID_DEBUG_BUFSIZE; - } + list_for_each_entry(list, &hdev->debug_list, node) + kfifo_in(&list->hid_debug_fifo, buf, strlen(buf)); spin_unlock_irqrestore(&hdev->debug_list_lock, flags); wake_up_interruptible(&hdev->debug_wait); @@ -722,8 +718,7 @@ void hid_dump_input(struct hid_device *hdev, struct hid_usage *usage, __s32 valu hid_debug_event(hdev, buf); kfree(buf); - wake_up_interruptible(&hdev->debug_wait); - + wake_up_interruptible(&hdev->debug_wait); } EXPORT_SYMBOL_GPL(hid_dump_input); @@ -1083,8 +1078,8 @@ static int hid_debug_events_open(struct inode *inode, struct file *file) goto out; } - if (!(list->hid_debug_buf = kzalloc(HID_DEBUG_BUFSIZE, GFP_KERNEL))) { - err = -ENOMEM; + err = kfifo_alloc(&list->hid_debug_fifo, HID_DEBUG_FIFOSIZE, GFP_KERNEL); + if (err) { kfree(list); goto out; } @@ -1104,77 +1099,55 @@ static ssize_t hid_debug_events_read(struct file *file, char __user *buffer, size_t count, loff_t *ppos) { struct hid_debug_list *list = file->private_data; - int ret = 0, len; + int ret = 0, copied; DECLARE_WAITQUEUE(wait, current); mutex_lock(&list->read_mutex); - while (ret == 0) { - if (list->head == list->tail) { - add_wait_queue(&list->hdev->debug_wait, &wait); - set_current_state(TASK_INTERRUPTIBLE); - - while (list->head == list->tail) { - if (file->f_flags & O_NONBLOCK) { - ret = -EAGAIN; - break; - } - if (signal_pending(current)) { - ret = -ERESTARTSYS; - break; - } - - if (!list->hdev || !list->hdev->debug) { - ret = -EIO; - set_current_state(TASK_RUNNING); - goto out; - } - - /* allow O_NONBLOCK from other threads */ - mutex_unlock(&list->read_mutex); - schedule(); - mutex_lock(&list->read_mutex); - set_current_state(TASK_INTERRUPTIBLE); - } - - set_current_state(TASK_RUNNING); - remove_wait_queue(&list->hdev->debug_wait, &wait); - } - - if (ret) - goto out; + if (kfifo_is_empty(&list->hid_debug_fifo)) { + add_wait_queue(&list->hdev->debug_wait, &wait); + set_current_state(TASK_INTERRUPTIBLE); + + while (kfifo_is_empty(&list->hid_debug_fifo)) { + if (file->f_flags & O_NONBLOCK) { + ret = -EAGAIN; + break; + } + + if (signal_pending(current)) { + ret = -ERESTARTSYS; + break; + } + + if (!list->hdev || !list->hdev->debug) { + ret = -EIO; + set_current_state(TASK_RUNNING); + goto out; + } + + /* allow O_NONBLOCK from other threads */ + mutex_unlock(&list->read_mutex); + schedule(); + mutex_lock(&list->read_mutex); + set_current_state(TASK_INTERRUPTIBLE); + } + + set_current_state(TASK_RUNNING); + remove_wait_queue(&list->hdev->debug_wait, &wait); + } + + if (ret) + goto out; + + if (kfifo_is_empty(&list->hid_debug_fifo)) + goto out; - /* pass the ringbuffer contents to userspace */ -copy_rest: - if (list->tail == list->head) - goto out; - if (list->tail > list->head) { - len = list->tail - list->head; - if (len > count) - len = count; - - if (copy_to_user(buffer + ret, &list->hid_debug_buf[list->head], len)) { - ret = -EFAULT; - goto out; - } - ret += len; - list->head += len; - } else { - len = HID_DEBUG_BUFSIZE - list->head; - if (len > count) - len = count; - - if (copy_to_user(buffer, &list->hid_debug_buf[list->head], len)) { - ret = -EFAULT; - goto out; - } - list->head = 0; - ret += len; - count -= len; - if (count > 0) - goto copy_rest; - } - - } + /* pass the fifo content to userspace, locking is not needed with only + * one concurrent reader and one concurrent writer + */ + ret = kfifo_to_user(&list->hid_debug_fifo, buffer, count, &copied); + if (ret) + goto out; + ret = copied; out: mutex_unlock(&list->read_mutex); return ret; @@ -1185,7 +1158,7 @@ static __poll_t hid_debug_events_poll(struct file *file, poll_table *wait) struct hid_debug_list *list = file->private_data; poll_wait(file, &list->hdev->debug_wait, wait); - if (list->head != list->tail) + if (!kfifo_is_empty(&list->hid_debug_fifo)) return EPOLLIN | EPOLLRDNORM; if (!list->hdev->debug) return EPOLLERR | EPOLLHUP; @@ -1200,7 +1173,7 @@ static int hid_debug_events_release(struct inode *inode, struct file *file) spin_lock_irqsave(&list->hdev->debug_list_lock, flags); list_del(&list->node); spin_unlock_irqrestore(&list->hdev->debug_list_lock, flags); - kfree(list->hid_debug_buf); + kfifo_free(&list->hid_debug_fifo); kfree(list); return 0; @@ -1246,4 +1219,3 @@ void hid_debug_exit(void) { debugfs_remove_recursive(hid_debug_root); } - diff --git a/include/linux/hid-debug.h b/include/linux/hid-debug.h index 8663f216c563..e7a7c92aaf09 100644 --- a/include/linux/hid-debug.h +++ b/include/linux/hid-debug.h @@ -24,7 +24,10 @@ #ifdef CONFIG_DEBUG_FS +#include <linux/kfifo.h> + #define HID_DEBUG_BUFSIZE 512 +#define HID_DEBUG_FIFOSIZE 512 void hid_dump_input(struct hid_device *, struct hid_usage *, __s32); void hid_dump_report(struct hid_device *, int , u8 *, int); @@ -38,10 +41,7 @@ void hid_debug_event(struct hid_device *, char *); void hid_debug_event(struct hid_device *, char *); - struct hid_debug_list { - char *hid_debug_buf; - int head; - int tail; + DECLARE_KFIFO_PTR(hid_debug_fifo, char); struct fasync_struct *fasync; struct hid_device *hdev; struct list_head node; @@ -64,4 +64,3 @@ struct hid_debug_list { #endif #endif -

6 years, 8 months

2
2
0 0

stable-rc/linux-4.19.y boot: 114 boots: 1 failed, 109 passed with 2 offline, 1 untried/unknown, 1 conflict (v4.19.18)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 114 boots: 1 failed, 109 passed with 2 offline, 1 untried/unknown, 1 conflict (v4.19.18) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.18/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.18 Git Commit: 34ae657246154f095288059157e722ccf69f3b63 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 63 unique boards, 23 SoC families, 12 builds out of 202 Boot Regressions Detected: arm: tegra_defconfig: tegra124-nyan-big: lab-collabora: new failure (last pass: v4.19.17-107-g3784655a0f02) arm64: defconfig: meson-gxl-s905x-khadas-vim: lab-baylibre-seattle: failing since 4 days (last pass: v4.19.16 - first fail: v4.19.16-100-ge43bc298813d) Boot Failure Detected: arm: tegra_defconfig tegra124-nyan-big: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: exynos5800-peach-pi: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm64: defconfig: meson-gxl-s905x-khadas-vim: lab-baylibre: PASS lab-baylibre-seattle: FAIL --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

PASS: Test report for kernel 4.20.5.cki (linux-stable-rc)

by CKI

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 9f1a389a0b5b Linux 4.20.5 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/s390x/9f1a389a0b5b4004757759e26e2f… powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/9f1a389a0b5b4004757759e26e… aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/9f1a389a0b5b4004757759e26e… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/9f1a389a0b5b4004757759e26e2… Hardware testing ---------------- We booted each kernel and ran the following tests: s390: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… Memory function: memfd_create - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/memory/func… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Networking route: pmtu - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… powerpc: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: ext4 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… Memory function: memfd_create - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/memory/func… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Networking route: pmtu - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… arm64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: ext4 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… Memory function: memfd_create - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/memory/func… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Networking route: pmtu - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… x86_64: Boot test - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… /distribution/command LTP lite - release 20180926 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… xfstests: ext4 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… xfstests: xfs - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… Memory function: memfd_create - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/memory/func… AMTU (Abstract Machine Test Utility) - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu Networking route: pmtu - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… Usex - version 1.9-29 - URL: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us…

6 years, 8 months

1
0
0 0

stable/linux-4.9.y boot: 98 boots: 0 failed, 96 passed with 2 offline (v4.9.153)

by kernelci.org bot

stable/linux-4.9.y boot: 98 boots: 0 failed, 96 passed with 2 offline (v4.9.153) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.9.y/kernel/v4.9.153/ Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.9.y/kernel/v4.9.153/ Tree: stable Branch: linux-4.9.y Git Describe: v4.9.153 Git Commit: 189b75ad3fc2d4a0d40a818ca298526d254ccdc4 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 48 unique boards, 21 SoC families, 13 builds out of 192 Offline Platforms: arm: multi_v7_defconfig: exynos5800-peach-pi: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

stable-rc/linux-4.9.y boot: 98 boots: 0 failed, 96 passed with 2 offline (v4.9.153)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 98 boots: 0 failed, 96 passed with 2 offline (v4.9.153) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.153/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.153 Git Commit: 189b75ad3fc2d4a0d40a818ca298526d254ccdc4 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 48 unique boards, 21 SoC families, 13 builds out of 193 Offline Platforms: arm: multi_v7_defconfig: exynos5800-peach-pi: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

stable-rc/linux-4.20.y boot: 116 boots: 1 failed, 112 passed with 2 offline, 1 conflict (v4.20.5)

by kernelci.org bot

stable-rc/linux-4.20.y boot: 116 boots: 1 failed, 112 passed with 2 offline, 1 conflict (v4.20.5) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.20.y/kernel/v4.2… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.20.y/kernel/v4.20.5/ Tree: stable-rc Branch: linux-4.20.y Git Describe: v4.20.5 Git Commit: 9f1a389a0b5b4004757759e26e2ff459016515ac Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 65 unique boards, 23 SoC families, 13 builds out of 202 Boot Regressions Detected: arm64: defconfig: meson-gxl-s905x-khadas-vim: lab-baylibre-seattle: failing since 1 day (last pass: v4.20.4-128-g67963d8b5ca5 - first fail: v4.20.4-127-gc3515872cb7f) Boot Failure Detected: arm64: defconfig mt7622-rfb1: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: exynos5800-peach-pi: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm64: defconfig: meson-gxl-s905x-khadas-vim: lab-baylibre: PASS lab-baylibre-seattle: FAIL --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

stable-rc/linux-3.18.y boot: 51 boots: 0 failed, 48 passed with 2 offline, 1 conflict (v3.18.133)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 51 boots: 0 failed, 48 passed with 2 offline, 1 conflict (v3.18.133) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.133/ Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.133 Git Commit: 4c35624dcb3bce026bb08eb04085c187bafff863 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 21 unique boards, 11 SoC families, 11 builds out of 185 Boot Regressions Detected: arm: tegra_defconfig: tegra124-jetson-tk1: lab-baylibre: new failure (last pass: v3.18.132-53-g8887b6a3fea6) Offline Platforms: arm: multi_v7_defconfig: exynos5800-peach-pi: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: tegra_defconfig: tegra124-jetson-tk1: lab-baylibre: FAIL lab-baylibre-seattle: PASS lab-mhart: PASS lab-collabora: PASS --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

stable/linux-3.18.y boot: 51 boots: 0 failed, 49 passed with 2 offline (v3.18.133)

by kernelci.org bot

stable/linux-3.18.y boot: 51 boots: 0 failed, 49 passed with 2 offline (v3.18.133) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-3.18.y/kernel/v3.18.1… Full Build Summary: https://kernelci.org/build/stable/branch/linux-3.18.y/kernel/v3.18.133/ Tree: stable Branch: linux-3.18.y Git Describe: v3.18.133 Git Commit: 4c35624dcb3bce026bb08eb04085c187bafff863 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 21 unique boards, 11 SoC families, 11 builds out of 185 Offline Platforms: arm: multi_v7_defconfig: exynos5800-peach-pi: 1 offline lab exynos_defconfig: exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror