This is a note to let you know that I've just added the patch titled
scsi: lpfc: Correct issue leading to oops during link reset
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-correct-issue-leading-to-oops-during-link-reset.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: James Smart <james.smart(a)broadcom.com>
Date: Mon, 19 Dec 2016 15:07:23 -0800
Subject: scsi: lpfc: Correct issue leading to oops during link reset
From: James Smart <james.smart(a)broadcom.com>
[ Upstream commit e6c6acc0e0223ddaf867628d420ee196349c6fae ]
Correct issue leading to oops during link reset. Missing vport pointer.
[mkp: fixed typo]
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_sli.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -10006,6 +10006,7 @@ lpfc_sli_abort_iotag_issue(struct lpfc_h
iabt->ulpCommand = CMD_CLOSE_XRI_CN;
abtsiocbp->iocb_cmpl = lpfc_sli_abort_els_cmpl;
+ abtsiocbp->vport = vport;
lpfc_printf_vlog(vport, KERN_INFO, LOG_SLI,
"0339 Abort xri x%x, original iotag x%x, "
Patches currently in stable-queue which might be from james.smart(a)broadcom.com are
queue-4.9/scsi-lpfc-clear-the-vendorversion-in-the-plogi-plogi-acc-payload.patch
queue-4.9/scsi-lpfc-correct-host-name-in-symbolic_name-field.patch
queue-4.9/scsi-lpfc-fcoe-vport-enable-disable-does-not-bring-up-the-vport.patch
queue-4.9/scsi-lpfc-correct-issue-leading-to-oops-during-link-reset.patch
queue-4.9/scsi-lpfc-add-missing-memory-barrier.patch
This is a note to let you know that I've just added the patch titled
scsi: lpfc: Add missing memory barrier
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-add-missing-memory-barrier.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: James Smart <james.smart(a)broadcom.com>
Date: Mon, 19 Dec 2016 15:07:30 -0800
Subject: scsi: lpfc: Add missing memory barrier
From: James Smart <james.smart(a)broadcom.com>
[ Upstream commit 6b3b3bdb83b4ad51252d21bb13596db879e51850 ]
On loosely ordered memory systems (PPC for example), the WQE elements
were being updated in memory, but not necessarily flushed before the
separate doorbell was written to hw which would cause hw to dma the
WQE element. Thus, the hardware occasionally received partially
updated WQE data.
Add the memory barrier after updating the WQE memory.
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_sli.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -119,6 +119,8 @@ lpfc_sli4_wq_put(struct lpfc_queue *q, u
if (q->phba->sli3_options & LPFC_SLI4_PHWQ_ENABLED)
bf_set(wqe_wqid, &wqe->generic.wqe_com, q->queue_id);
lpfc_sli_pcimem_bcopy(wqe, temp_wqe, q->entry_size);
+ /* ensure WQE bcopy flushed before doorbell write */
+ wmb();
/* Update the host index before invoking device */
host_index = q->host_index;
Patches currently in stable-queue which might be from james.smart(a)broadcom.com are
queue-4.9/scsi-lpfc-clear-the-vendorversion-in-the-plogi-plogi-acc-payload.patch
queue-4.9/scsi-lpfc-correct-host-name-in-symbolic_name-field.patch
queue-4.9/scsi-lpfc-fcoe-vport-enable-disable-does-not-bring-up-the-vport.patch
queue-4.9/scsi-lpfc-correct-issue-leading-to-oops-during-link-reset.patch
queue-4.9/scsi-lpfc-add-missing-memory-barrier.patch
This is a note to let you know that I've just added the patch titled
Revert "uapi: fix linux/rds.h userspace compilation errors"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-uapi-fix-linux-rds.h-userspace-compilation-errors.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Sasha Levin <alexander.levin(a)verizon.com>
Date: Mon, 13 Nov 2017 18:03:32 -0500
Subject: Revert "uapi: fix linux/rds.h userspace compilation errors"
From: Sasha Levin <alexander.levin(a)verizon.com>
This reverts commit ad50561ba7a664bc581826c9d57d137fcf17bfa5.
There was a mixup with the commit message for two upstream commit
that have the same subject line.
This revert will be followed by the two commits with proper commit
messages.
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/rds.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/include/uapi/linux/rds.h
+++ b/include/uapi/linux/rds.h
@@ -35,7 +35,6 @@
#define _LINUX_RDS_H
#include <linux/types.h>
-#include <linux/socket.h> /* For __kernel_sockaddr_storage. */
#define RDS_IB_ABI_VERSION 0x301
@@ -224,7 +223,7 @@ struct rds_get_mr_args {
};
struct rds_get_mr_for_dest_args {
- struct __kernel_sockaddr_storage dest_addr;
+ struct sockaddr_storage dest_addr;
struct rds_iovec vec;
uint64_t cookie_addr;
uint64_t flags;
Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are
queue-4.9/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.9/scsi-lpfc-clear-the-vendorversion-in-the-plogi-plogi-acc-payload.patch
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
queue-4.9/extcon-remove-potential-problem-when-calling-extcon_register_notifier.patch
queue-4.9/scsi-lpfc-correct-host-name-in-symbolic_name-field.patch
queue-4.9/alsa-vx-don-t-try-to-update-capture-stream-before-running.patch
queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch
queue-4.9/gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
queue-4.9/staging-rtl8188eu-fix-incorrect-error-tags-from-logs.patch
queue-4.9/uapi-fix-linux-rds.h-userspace-compilation-error.patch
queue-4.9/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-15-bit-values-2-registers-at-a-time.patch
queue-4.9/mips-init-ensure-bootmem-does-not-corrupt-reserved-memory.patch
queue-4.9/extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
queue-4.9/scsi-lpfc-fcoe-vport-enable-disable-does-not-bring-up-the-vport.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-12-bit-values-2-registers-at-a-time.patch
queue-4.9/revert-dt-bindings-add-vendor-prefix-for-lego.patch
queue-4.9/mips-netlogic-exclude-netlogic-xlp-pic-code-from-xlr-builds.patch
queue-4.9/drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
queue-4.9/ixgbe-reduce-i2c-retry-count-on-x550-devices.patch
queue-4.9/ixgbe-do-not-disable-fec-from-the-driver.patch
queue-4.9/x86-irq-trace-add-__irq_entry-annotation-to-x86-s-platform-irq-handlers.patch
queue-4.9/scsi-lpfc-correct-issue-leading-to-oops-during-link-reset.patch
queue-4.9/igb-fix-hw_dbg-logging-in-igb_update_flash_i210.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/uapi-fix-linux-rds.h-userspace-compilation-errors.patch
queue-4.9/scsi-lpfc-add-missing-memory-barrier.patch
queue-4.9/alsa-vx-fix-possible-transfer-overflow.patch
queue-4.9/backlight-lcd-fix-race-condition-during-register.patch
queue-4.9/fm10k-request-reset-when-mbx-state-changes.patch
queue-4.9/arm64-dts-ns2-reserve-memory-for-nitro-firmware.patch
queue-4.9/staging-rtl8712-fixed-little-endian-problem.patch
queue-4.9/revert-crypto-xts-add-ecb-dependency.patch
queue-4.9/backlight-adp5520-fix-error-handling-in-adp5520_bl_probe.patch
queue-4.9/staging-wilc1000-fix-endian-sparse-warning.patch
queue-4.9/alsa-hda-realtek-add-new-codec-id-alc299.patch
queue-4.9/ixgbe-fix-aer-error-handling.patch
queue-4.9/scsi-ufs-add-capability-to-keep-auto-bkops-always-enabled.patch
queue-4.9/tcp-provide-timestamps-for-partial-writes.patch
queue-4.9/revert-uapi-fix-linux-rds.h-userspace-compilation-errors.patch
queue-4.9/ixgbe-configure-advertised-speeds-correctly-for-kr-kx-backplane.patch
queue-4.9/mips-traps-ensure-l1-l2-ecc-checking-match-for-cm3-systems.patch
queue-4.9/ixgbe-add-mask-for-64-rss-queues.patch
queue-4.9/revert-dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-4.9/rtc-rx8010-change-lock-mechanism.patch
queue-4.9/mips-end-asm-function-prologue-macros-with-.insn.patch
queue-4.9/ata-ata_bmdma-should-depend-on-has_dma.patch
queue-4.9/drm-omap-panel-sony-acx565akm.c-add-module_alias.patch
queue-4.9/ixgbe-fix-reporting-of-100mb-capability.patch
queue-4.9/igb-close-suspend-race-in-netif_device_detach.patch
queue-4.9/igb-reset-the-phy-before-reading-the-phy-id.patch
queue-4.9/mips-init-ensure-reserved-memory-regions-are-not-added-to-bootmem.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/scsi-ufs-qcom-fix-module-autoload.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
Revert "crypto: xts - Add ECB dependency"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-crypto-xts-add-ecb-dependency.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Sasha Levin <alexander.levin(a)verizon.com>
Date: Mon, 13 Nov 2017 17:55:20 -0500
Subject: Revert "crypto: xts - Add ECB dependency"
From: Sasha Levin <alexander.levin(a)verizon.com>
This reverts commit 6145171a6bc0abdc3eca7a4b795ede467d2ba569.
The commit fixes a bug that was only introduced in 4.10, thus is
irrelevant for <=4.9.
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/Kconfig | 1 -
1 file changed, 1 deletion(-)
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -360,7 +360,6 @@ config CRYPTO_XTS
select CRYPTO_BLKCIPHER
select CRYPTO_MANAGER
select CRYPTO_GF128MUL
- select CRYPTO_ECB
help
XTS: IEEE1619/D16 narrow block cipher use with aes-xts-plain,
key size 256, 384 or 512 bits. This implementation currently
Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are
queue-4.9/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.9/scsi-lpfc-clear-the-vendorversion-in-the-plogi-plogi-acc-payload.patch
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
queue-4.9/extcon-remove-potential-problem-when-calling-extcon_register_notifier.patch
queue-4.9/scsi-lpfc-correct-host-name-in-symbolic_name-field.patch
queue-4.9/alsa-vx-don-t-try-to-update-capture-stream-before-running.patch
queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch
queue-4.9/gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
queue-4.9/staging-rtl8188eu-fix-incorrect-error-tags-from-logs.patch
queue-4.9/uapi-fix-linux-rds.h-userspace-compilation-error.patch
queue-4.9/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-15-bit-values-2-registers-at-a-time.patch
queue-4.9/mips-init-ensure-bootmem-does-not-corrupt-reserved-memory.patch
queue-4.9/extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
queue-4.9/scsi-lpfc-fcoe-vport-enable-disable-does-not-bring-up-the-vport.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-12-bit-values-2-registers-at-a-time.patch
queue-4.9/revert-dt-bindings-add-vendor-prefix-for-lego.patch
queue-4.9/mips-netlogic-exclude-netlogic-xlp-pic-code-from-xlr-builds.patch
queue-4.9/drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
queue-4.9/ixgbe-reduce-i2c-retry-count-on-x550-devices.patch
queue-4.9/ixgbe-do-not-disable-fec-from-the-driver.patch
queue-4.9/x86-irq-trace-add-__irq_entry-annotation-to-x86-s-platform-irq-handlers.patch
queue-4.9/scsi-lpfc-correct-issue-leading-to-oops-during-link-reset.patch
queue-4.9/igb-fix-hw_dbg-logging-in-igb_update_flash_i210.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/uapi-fix-linux-rds.h-userspace-compilation-errors.patch
queue-4.9/scsi-lpfc-add-missing-memory-barrier.patch
queue-4.9/alsa-vx-fix-possible-transfer-overflow.patch
queue-4.9/backlight-lcd-fix-race-condition-during-register.patch
queue-4.9/fm10k-request-reset-when-mbx-state-changes.patch
queue-4.9/arm64-dts-ns2-reserve-memory-for-nitro-firmware.patch
queue-4.9/staging-rtl8712-fixed-little-endian-problem.patch
queue-4.9/revert-crypto-xts-add-ecb-dependency.patch
queue-4.9/backlight-adp5520-fix-error-handling-in-adp5520_bl_probe.patch
queue-4.9/staging-wilc1000-fix-endian-sparse-warning.patch
queue-4.9/alsa-hda-realtek-add-new-codec-id-alc299.patch
queue-4.9/ixgbe-fix-aer-error-handling.patch
queue-4.9/scsi-ufs-add-capability-to-keep-auto-bkops-always-enabled.patch
queue-4.9/tcp-provide-timestamps-for-partial-writes.patch
queue-4.9/revert-uapi-fix-linux-rds.h-userspace-compilation-errors.patch
queue-4.9/ixgbe-configure-advertised-speeds-correctly-for-kr-kx-backplane.patch
queue-4.9/mips-traps-ensure-l1-l2-ecc-checking-match-for-cm3-systems.patch
queue-4.9/ixgbe-add-mask-for-64-rss-queues.patch
queue-4.9/revert-dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-4.9/rtc-rx8010-change-lock-mechanism.patch
queue-4.9/mips-end-asm-function-prologue-macros-with-.insn.patch
queue-4.9/ata-ata_bmdma-should-depend-on-has_dma.patch
queue-4.9/drm-omap-panel-sony-acx565akm.c-add-module_alias.patch
queue-4.9/ixgbe-fix-reporting-of-100mb-capability.patch
queue-4.9/igb-close-suspend-race-in-netif_device_detach.patch
queue-4.9/igb-reset-the-phy-before-reading-the-phy-id.patch
queue-4.9/mips-init-ensure-reserved-memory-regions-are-not-added-to-bootmem.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/scsi-ufs-qcom-fix-module-autoload.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
Revert "dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Sasha Levin <alexander.levin(a)verizon.com>
Date: Thu, 16 Nov 2017 21:04:58 -0500
Subject: Revert "dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification"
From: Sasha Levin <alexander.levin(a)verizon.com>
This reverts commit 852bf68b7a62195c3c0c63f3b11f3f30958fc220.
As Ben pointed out, these drivers don't exist in <=4.9.
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/arm/davinci.txt | 4 ----
1 file changed, 4 deletions(-)
--- a/Documentation/devicetree/bindings/arm/davinci.txt
+++ b/Documentation/devicetree/bindings/arm/davinci.txt
@@ -13,10 +13,6 @@ EnBW AM1808 based CMC board
Required root node properties:
- compatible = "enbw,cmc", "ti,da850;
-LEGO MINDSTORMS EV3 (AM1808 based)
-Required root node properties:
- - compatible = "lego,ev3", "ti,da850";
-
Generic DaVinci Boards
----------------------
Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are
queue-4.9/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.9/scsi-lpfc-clear-the-vendorversion-in-the-plogi-plogi-acc-payload.patch
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
queue-4.9/extcon-remove-potential-problem-when-calling-extcon_register_notifier.patch
queue-4.9/scsi-lpfc-correct-host-name-in-symbolic_name-field.patch
queue-4.9/alsa-vx-don-t-try-to-update-capture-stream-before-running.patch
queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch
queue-4.9/gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
queue-4.9/staging-rtl8188eu-fix-incorrect-error-tags-from-logs.patch
queue-4.9/uapi-fix-linux-rds.h-userspace-compilation-error.patch
queue-4.9/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-15-bit-values-2-registers-at-a-time.patch
queue-4.9/mips-init-ensure-bootmem-does-not-corrupt-reserved-memory.patch
queue-4.9/extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
queue-4.9/scsi-lpfc-fcoe-vport-enable-disable-does-not-bring-up-the-vport.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-12-bit-values-2-registers-at-a-time.patch
queue-4.9/revert-dt-bindings-add-vendor-prefix-for-lego.patch
queue-4.9/mips-netlogic-exclude-netlogic-xlp-pic-code-from-xlr-builds.patch
queue-4.9/drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
queue-4.9/ixgbe-reduce-i2c-retry-count-on-x550-devices.patch
queue-4.9/ixgbe-do-not-disable-fec-from-the-driver.patch
queue-4.9/x86-irq-trace-add-__irq_entry-annotation-to-x86-s-platform-irq-handlers.patch
queue-4.9/scsi-lpfc-correct-issue-leading-to-oops-during-link-reset.patch
queue-4.9/igb-fix-hw_dbg-logging-in-igb_update_flash_i210.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/uapi-fix-linux-rds.h-userspace-compilation-errors.patch
queue-4.9/scsi-lpfc-add-missing-memory-barrier.patch
queue-4.9/alsa-vx-fix-possible-transfer-overflow.patch
queue-4.9/backlight-lcd-fix-race-condition-during-register.patch
queue-4.9/fm10k-request-reset-when-mbx-state-changes.patch
queue-4.9/arm64-dts-ns2-reserve-memory-for-nitro-firmware.patch
queue-4.9/staging-rtl8712-fixed-little-endian-problem.patch
queue-4.9/revert-crypto-xts-add-ecb-dependency.patch
queue-4.9/backlight-adp5520-fix-error-handling-in-adp5520_bl_probe.patch
queue-4.9/staging-wilc1000-fix-endian-sparse-warning.patch
queue-4.9/alsa-hda-realtek-add-new-codec-id-alc299.patch
queue-4.9/ixgbe-fix-aer-error-handling.patch
queue-4.9/scsi-ufs-add-capability-to-keep-auto-bkops-always-enabled.patch
queue-4.9/tcp-provide-timestamps-for-partial-writes.patch
queue-4.9/revert-uapi-fix-linux-rds.h-userspace-compilation-errors.patch
queue-4.9/ixgbe-configure-advertised-speeds-correctly-for-kr-kx-backplane.patch
queue-4.9/mips-traps-ensure-l1-l2-ecc-checking-match-for-cm3-systems.patch
queue-4.9/ixgbe-add-mask-for-64-rss-queues.patch
queue-4.9/revert-dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-4.9/rtc-rx8010-change-lock-mechanism.patch
queue-4.9/mips-end-asm-function-prologue-macros-with-.insn.patch
queue-4.9/ata-ata_bmdma-should-depend-on-has_dma.patch
queue-4.9/drm-omap-panel-sony-acx565akm.c-add-module_alias.patch
queue-4.9/ixgbe-fix-reporting-of-100mb-capability.patch
queue-4.9/igb-close-suspend-race-in-netif_device_detach.patch
queue-4.9/igb-reset-the-phy-before-reading-the-phy-id.patch
queue-4.9/mips-init-ensure-reserved-memory-regions-are-not-added-to-bootmem.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/scsi-ufs-qcom-fix-module-autoload.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
Revert "dt-bindings: Add vendor prefix for LEGO"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-dt-bindings-add-vendor-prefix-for-lego.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Sasha Levin <alexander.levin(a)verizon.com>
Date: Thu, 16 Nov 2017 21:04:38 -0500
Subject: Revert "dt-bindings: Add vendor prefix for LEGO"
From: Sasha Levin <alexander.levin(a)verizon.com>
This reverts commit 04e13a5ec96db94c1cc8ce7b0b1e1b626e0c00c7.
As Ben pointed out, these drivers don't exist in <=4.9.
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 -
1 file changed, 1 deletion(-)
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -154,7 +154,6 @@ kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
lantiq Lantiq Semiconductor
-lego LEGO Systems A/S
lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are
queue-4.9/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.9/scsi-lpfc-clear-the-vendorversion-in-the-plogi-plogi-acc-payload.patch
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
queue-4.9/extcon-remove-potential-problem-when-calling-extcon_register_notifier.patch
queue-4.9/scsi-lpfc-correct-host-name-in-symbolic_name-field.patch
queue-4.9/alsa-vx-don-t-try-to-update-capture-stream-before-running.patch
queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch
queue-4.9/gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
queue-4.9/staging-rtl8188eu-fix-incorrect-error-tags-from-logs.patch
queue-4.9/uapi-fix-linux-rds.h-userspace-compilation-error.patch
queue-4.9/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-15-bit-values-2-registers-at-a-time.patch
queue-4.9/mips-init-ensure-bootmem-does-not-corrupt-reserved-memory.patch
queue-4.9/extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
queue-4.9/scsi-lpfc-fcoe-vport-enable-disable-does-not-bring-up-the-vport.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-12-bit-values-2-registers-at-a-time.patch
queue-4.9/revert-dt-bindings-add-vendor-prefix-for-lego.patch
queue-4.9/mips-netlogic-exclude-netlogic-xlp-pic-code-from-xlr-builds.patch
queue-4.9/drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
queue-4.9/ixgbe-reduce-i2c-retry-count-on-x550-devices.patch
queue-4.9/ixgbe-do-not-disable-fec-from-the-driver.patch
queue-4.9/x86-irq-trace-add-__irq_entry-annotation-to-x86-s-platform-irq-handlers.patch
queue-4.9/scsi-lpfc-correct-issue-leading-to-oops-during-link-reset.patch
queue-4.9/igb-fix-hw_dbg-logging-in-igb_update_flash_i210.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/uapi-fix-linux-rds.h-userspace-compilation-errors.patch
queue-4.9/scsi-lpfc-add-missing-memory-barrier.patch
queue-4.9/alsa-vx-fix-possible-transfer-overflow.patch
queue-4.9/backlight-lcd-fix-race-condition-during-register.patch
queue-4.9/fm10k-request-reset-when-mbx-state-changes.patch
queue-4.9/arm64-dts-ns2-reserve-memory-for-nitro-firmware.patch
queue-4.9/staging-rtl8712-fixed-little-endian-problem.patch
queue-4.9/revert-crypto-xts-add-ecb-dependency.patch
queue-4.9/backlight-adp5520-fix-error-handling-in-adp5520_bl_probe.patch
queue-4.9/staging-wilc1000-fix-endian-sparse-warning.patch
queue-4.9/alsa-hda-realtek-add-new-codec-id-alc299.patch
queue-4.9/ixgbe-fix-aer-error-handling.patch
queue-4.9/scsi-ufs-add-capability-to-keep-auto-bkops-always-enabled.patch
queue-4.9/tcp-provide-timestamps-for-partial-writes.patch
queue-4.9/revert-uapi-fix-linux-rds.h-userspace-compilation-errors.patch
queue-4.9/ixgbe-configure-advertised-speeds-correctly-for-kr-kx-backplane.patch
queue-4.9/mips-traps-ensure-l1-l2-ecc-checking-match-for-cm3-systems.patch
queue-4.9/ixgbe-add-mask-for-64-rss-queues.patch
queue-4.9/revert-dt-bindings-add-lego-mindstorms-ev3-compatible-specification.patch
queue-4.9/rtc-rx8010-change-lock-mechanism.patch
queue-4.9/mips-end-asm-function-prologue-macros-with-.insn.patch
queue-4.9/ata-ata_bmdma-should-depend-on-has_dma.patch
queue-4.9/drm-omap-panel-sony-acx565akm.c-add-module_alias.patch
queue-4.9/ixgbe-fix-reporting-of-100mb-capability.patch
queue-4.9/igb-close-suspend-race-in-netif_device_detach.patch
queue-4.9/igb-reset-the-phy-before-reading-the-phy-id.patch
queue-4.9/mips-init-ensure-reserved-memory-regions-are-not-added-to-bootmem.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/scsi-ufs-qcom-fix-module-autoload.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
power: supply: axp288_fuel_gauge: Read 15 bit values 2 registers at a time
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
power-supply-axp288_fuel_gauge-read-15-bit-values-2-registers-at-a-time.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 14 Dec 2016 17:38:51 +0100
Subject: power: supply: axp288_fuel_gauge: Read 15 bit values 2 registers at a time
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 4949fc5e071f8e8d8122e0b16cf6a2ec1ca36258 ]
In order for the MSB -> LSB latching to work correctly we must read the
2 8 bit registers of a 15 bit value in one consecutive read.
This fixes charge_full reporting 3498768 on some reads and 3354624 one
other reads on my tablet (for the 3354624 value the raw LSB is 0x00).
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Sebastian Reichel <sre(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/supply/axp288_fuel_gauge.c | 63 ++++++++++++++++---------------
1 file changed, 34 insertions(+), 29 deletions(-)
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -29,6 +29,7 @@
#include <linux/iio/consumer.h>
#include <linux/debugfs.h>
#include <linux/seq_file.h>
+#include <asm/unaligned.h>
#define CHRG_STAT_BAT_SAFE_MODE (1 << 3)
#define CHRG_STAT_BAT_VALID (1 << 4)
@@ -73,17 +74,15 @@
#define FG_CNTL_CC_EN (1 << 6)
#define FG_CNTL_GAUGE_EN (1 << 7)
+#define FG_15BIT_WORD_VALID (1 << 15)
+#define FG_15BIT_VAL_MASK 0x7fff
+
#define FG_REP_CAP_VALID (1 << 7)
#define FG_REP_CAP_VAL_MASK 0x7F
#define FG_DES_CAP1_VALID (1 << 7)
-#define FG_DES_CAP1_VAL_MASK 0x7F
-#define FG_DES_CAP0_VAL_MASK 0xFF
#define FG_DES_CAP_RES_LSB 1456 /* 1.456mAhr */
-#define FG_CC_MTR1_VALID (1 << 7)
-#define FG_CC_MTR1_VAL_MASK 0x7F
-#define FG_CC_MTR0_VAL_MASK 0xFF
#define FG_DES_CC_RES_LSB 1456 /* 1.456mAhr */
#define FG_OCV_CAP_VALID (1 << 7)
@@ -189,6 +188,28 @@ static int fuel_gauge_reg_writeb(struct
return ret;
}
+static int fuel_gauge_read_15bit_word(struct axp288_fg_info *info, int reg)
+{
+ unsigned char buf[2];
+ int ret;
+
+ ret = regmap_bulk_read(info->regmap, reg, buf, 2);
+ if (ret < 0) {
+ dev_err(&info->pdev->dev, "Error reading reg 0x%02x err: %d\n",
+ reg, ret);
+ return ret;
+ }
+
+ ret = get_unaligned_be16(buf);
+ if (!(ret & FG_15BIT_WORD_VALID)) {
+ dev_err(&info->pdev->dev, "Error reg 0x%02x contents not valid\n",
+ reg);
+ return -ENXIO;
+ }
+
+ return ret & FG_15BIT_VAL_MASK;
+}
+
static int pmic_read_adc_val(const char *name, int *raw_val,
struct axp288_fg_info *info)
{
@@ -255,18 +276,12 @@ static int fuel_gauge_debug_show(struct
seq_printf(s, " FG_OCVL[%02x] : %02x\n",
AXP288_FG_OCVL_REG,
fuel_gauge_reg_readb(info, AXP288_FG_OCVL_REG));
- seq_printf(s, "FG_DES_CAP1[%02x] : %02x\n",
+ seq_printf(s, " FG_DES_CAP[%02x] : %04x\n",
AXP288_FG_DES_CAP1_REG,
- fuel_gauge_reg_readb(info, AXP288_FG_DES_CAP1_REG));
- seq_printf(s, "FG_DES_CAP0[%02x] : %02x\n",
- AXP288_FG_DES_CAP0_REG,
- fuel_gauge_reg_readb(info, AXP288_FG_DES_CAP0_REG));
- seq_printf(s, " FG_CC_MTR1[%02x] : %02x\n",
+ fuel_gauge_read_15bit_word(info, AXP288_FG_DES_CAP1_REG));
+ seq_printf(s, " FG_CC_MTR[%02x] : %04x\n",
AXP288_FG_CC_MTR1_REG,
- fuel_gauge_reg_readb(info, AXP288_FG_CC_MTR1_REG));
- seq_printf(s, " FG_CC_MTR0[%02x] : %02x\n",
- AXP288_FG_CC_MTR0_REG,
- fuel_gauge_reg_readb(info, AXP288_FG_CC_MTR0_REG));
+ fuel_gauge_read_15bit_word(info, AXP288_FG_CC_MTR1_REG));
seq_printf(s, " FG_OCV_CAP[%02x] : %02x\n",
AXP288_FG_OCV_CAP_REG,
fuel_gauge_reg_readb(info, AXP288_FG_OCV_CAP_REG));
@@ -663,28 +678,18 @@ static int fuel_gauge_get_property(struc
val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
break;
case POWER_SUPPLY_PROP_CHARGE_NOW:
- ret = fuel_gauge_reg_readb(info, AXP288_FG_CC_MTR1_REG);
+ ret = fuel_gauge_read_15bit_word(info, AXP288_FG_CC_MTR1_REG);
if (ret < 0)
goto fuel_gauge_read_err;
- value = (ret & FG_CC_MTR1_VAL_MASK) << 8;
- ret = fuel_gauge_reg_readb(info, AXP288_FG_CC_MTR0_REG);
- if (ret < 0)
- goto fuel_gauge_read_err;
- value |= (ret & FG_CC_MTR0_VAL_MASK);
- val->intval = value * FG_DES_CAP_RES_LSB;
+ val->intval = ret * FG_DES_CAP_RES_LSB;
break;
case POWER_SUPPLY_PROP_CHARGE_FULL:
- ret = fuel_gauge_reg_readb(info, AXP288_FG_DES_CAP1_REG);
+ ret = fuel_gauge_read_15bit_word(info, AXP288_FG_DES_CAP1_REG);
if (ret < 0)
goto fuel_gauge_read_err;
- value = (ret & FG_DES_CAP1_VAL_MASK) << 8;
- ret = fuel_gauge_reg_readb(info, AXP288_FG_DES_CAP0_REG);
- if (ret < 0)
- goto fuel_gauge_read_err;
- value |= (ret & FG_DES_CAP0_VAL_MASK);
- val->intval = value * FG_DES_CAP_RES_LSB;
+ val->intval = ret * FG_DES_CAP_RES_LSB;
break;
case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
val->intval = PROP_CURR(info->pdata->design_cap);
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/power-supply-axp288_fuel_gauge-read-15-bit-values-2-registers-at-a-time.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-12-bit-values-2-registers-at-a-time.patch
This is a note to let you know that I've just added the patch titled
power: supply: axp288_fuel_gauge: Read 12 bit values 2 registers at a time
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
power-supply-axp288_fuel_gauge-read-12-bit-values-2-registers-at-a-time.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 14 Dec 2016 17:38:52 +0100
Subject: power: supply: axp288_fuel_gauge: Read 12 bit values 2 registers at a time
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 248efcf00602f0282587999bcc221a872bd72530 ]
In order for the MSB -> LSB latching to work correctly we must read the
2 8 bit registers of a 12 bit value in one consecutive read.
This fixes voltage_ocv reporting inconsistent values on my tablet.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Sebastian Reichel <sre(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/supply/axp288_fuel_gauge.c | 40 +++++++++++++++++--------------
1 file changed, 22 insertions(+), 18 deletions(-)
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -210,6 +210,22 @@ static int fuel_gauge_read_15bit_word(st
return ret & FG_15BIT_VAL_MASK;
}
+static int fuel_gauge_read_12bit_word(struct axp288_fg_info *info, int reg)
+{
+ unsigned char buf[2];
+ int ret;
+
+ ret = regmap_bulk_read(info->regmap, reg, buf, 2);
+ if (ret < 0) {
+ dev_err(&info->pdev->dev, "Error reading reg 0x%02x err: %d\n",
+ reg, ret);
+ return ret;
+ }
+
+ /* 12-bit data values have upper 8 bits in buf[0], lower 4 in buf[1] */
+ return (buf[0] << 4) | ((buf[1] >> 4) & 0x0f);
+}
+
static int pmic_read_adc_val(const char *name, int *raw_val,
struct axp288_fg_info *info)
{
@@ -270,12 +286,9 @@ static int fuel_gauge_debug_show(struct
seq_printf(s, " FG_RDC0[%02x] : %02x\n",
AXP288_FG_RDC0_REG,
fuel_gauge_reg_readb(info, AXP288_FG_RDC0_REG));
- seq_printf(s, " FG_OCVH[%02x] : %02x\n",
+ seq_printf(s, " FG_OCV[%02x] : %04x\n",
AXP288_FG_OCVH_REG,
- fuel_gauge_reg_readb(info, AXP288_FG_OCVH_REG));
- seq_printf(s, " FG_OCVL[%02x] : %02x\n",
- AXP288_FG_OCVL_REG,
- fuel_gauge_reg_readb(info, AXP288_FG_OCVL_REG));
+ fuel_gauge_read_12bit_word(info, AXP288_FG_OCVH_REG));
seq_printf(s, " FG_DES_CAP[%02x] : %04x\n",
AXP288_FG_DES_CAP1_REG,
fuel_gauge_read_15bit_word(info, AXP288_FG_DES_CAP1_REG));
@@ -532,21 +545,12 @@ temp_read_fail:
static int fuel_gauge_get_vocv(struct axp288_fg_info *info, int *vocv)
{
- int ret, value;
-
- /* 12-bit data value, upper 8 in OCVH, lower 4 in OCVL */
- ret = fuel_gauge_reg_readb(info, AXP288_FG_OCVH_REG);
- if (ret < 0)
- goto vocv_read_fail;
- value = ret << 4;
+ int ret;
- ret = fuel_gauge_reg_readb(info, AXP288_FG_OCVL_REG);
- if (ret < 0)
- goto vocv_read_fail;
- value |= (ret & 0xf);
+ ret = fuel_gauge_read_12bit_word(info, AXP288_FG_OCVH_REG);
+ if (ret >= 0)
+ *vocv = VOLTAGE_FROM_ADC(ret);
- *vocv = VOLTAGE_FROM_ADC(value);
-vocv_read_fail:
return ret;
}
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/power-supply-axp288_fuel_gauge-read-15-bit-values-2-registers-at-a-time.patch
queue-4.9/power-supply-axp288_fuel_gauge-read-12-bit-values-2-registers-at-a-time.patch
This is a note to let you know that I've just added the patch titled
MIPS: Netlogic: Exclude netlogic,xlp-pic code from XLR builds
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-netlogic-exclude-netlogic-xlp-pic-code-from-xlr-builds.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Paul Burton <paul.burton(a)imgtec.com>
Date: Mon, 7 Nov 2016 11:30:41 +0000
Subject: MIPS: Netlogic: Exclude netlogic,xlp-pic code from XLR builds
From: Paul Burton <paul.burton(a)imgtec.com>
[ Upstream commit 9799270affc53414da96e77e454a5616b39cdab0 ]
Code in arch/mips/netlogic/common/irq.c which handles the XLP PIC fails
to build in XLR configurations due to cpu_is_xlp9xx not being defined,
leading to the following build failure:
arch/mips/netlogic/common/irq.c: In function ‘xlp_of_pic_init’:
arch/mips/netlogic/common/irq.c:298:2: error: implicit declaration
of function ‘cpu_is_xlp9xx’ [-Werror=implicit-function-declaration]
if (cpu_is_xlp9xx()) {
^
Although the code was conditional upon CONFIG_OF which is indirectly
selected by CONFIG_NLM_XLP_BOARD but not CONFIG_NLM_XLR_BOARD, the
failing XLR with CONFIG_OF configuration can be configured manually or
by randconfig.
Fix the build failure by making the affected XLP PIC code conditional
upon CONFIG_CPU_XLP which is used to guard the inclusion of
asm/netlogic/xlp-hal/xlp.h that provides the required cpu_is_xlp9xx
function.
[ralf(a)linux-mips.org: Fixed up as per Jayachandran's suggestion.]
Signed-off-by: Paul Burton <paul.burton(a)imgtec.com>
Cc: Jayachandran C <jchandra(a)broadcom.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14524/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/netlogic/common/irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/mips/netlogic/common/irq.c
+++ b/arch/mips/netlogic/common/irq.c
@@ -275,7 +275,7 @@ asmlinkage void plat_irq_dispatch(void)
do_IRQ(nlm_irq_to_xirq(node, i));
}
-#ifdef CONFIG_OF
+#ifdef CONFIG_CPU_XLP
static const struct irq_domain_ops xlp_pic_irq_domain_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
@@ -348,7 +348,7 @@ void __init arch_init_irq(void)
#if defined(CONFIG_CPU_XLR)
nlm_setup_fmn_irq();
#endif
-#if defined(CONFIG_OF)
+#ifdef CONFIG_CPU_XLP
of_irq_init(xlp_pic_irq_ids);
#endif
}
Patches currently in stable-queue which might be from paul.burton(a)imgtec.com are
queue-4.9/mips-netlogic-exclude-netlogic-xlp-pic-code-from-xlr-builds.patch
queue-4.9/mips-traps-ensure-l1-l2-ecc-checking-match-for-cm3-systems.patch
queue-4.9/mips-end-asm-function-prologue-macros-with-.insn.patch
This is a note to let you know that I've just added the patch titled
MIPS: traps: Ensure L1 & L2 ECC checking match for CM3 systems
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-traps-ensure-l1-l2-ecc-checking-match-for-cm3-systems.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Paul Burton <paul.burton(a)imgtec.com>
Date: Mon, 17 Oct 2016 16:01:07 +0100
Subject: MIPS: traps: Ensure L1 & L2 ECC checking match for CM3 systems
From: Paul Burton <paul.burton(a)imgtec.com>
[ Upstream commit 35e6de38858f59b6b65dcfeaf700b5d06fc2b93d ]
On systems with CM3, we must ensure that the L1 & L2 ECC enables are set
to the same value. This is presumed by the hardware & cache corruption
can occur when it is not the case. Support enabling & disabling the L2
ECC checking on CM3 systems where this is controlled via a GCR, and
ensure that it matches the state of L1 ECC checking. Remove I6400 from
the switch statement it will no longer hit, and which was incorrect
since the L2 ECC enable bit isn't in the CP0 ErrCtl register.
Signed-off-by: Paul Burton <paul.burton(a)imgtec.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14413/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/include/asm/mips-cm.h | 7 ++++
arch/mips/kernel/traps.c | 63 ++++++++++++++++++++++++++++++++++++++--
2 files changed, 67 insertions(+), 3 deletions(-)
--- a/arch/mips/include/asm/mips-cm.h
+++ b/arch/mips/include/asm/mips-cm.h
@@ -187,6 +187,7 @@ BUILD_CM_R_(config, MIPS_CM_GCB_OFS + 0
BUILD_CM_RW(base, MIPS_CM_GCB_OFS + 0x08)
BUILD_CM_RW(access, MIPS_CM_GCB_OFS + 0x20)
BUILD_CM_R_(rev, MIPS_CM_GCB_OFS + 0x30)
+BUILD_CM_RW(err_control, MIPS_CM_GCB_OFS + 0x38)
BUILD_CM_RW(error_mask, MIPS_CM_GCB_OFS + 0x40)
BUILD_CM_RW(error_cause, MIPS_CM_GCB_OFS + 0x48)
BUILD_CM_RW(error_addr, MIPS_CM_GCB_OFS + 0x50)
@@ -266,6 +267,12 @@ BUILD_CM_Cx_R_(tcid_8_priority, 0x80)
#define CM_REV_CM2_5 CM_ENCODE_REV(7, 0)
#define CM_REV_CM3 CM_ENCODE_REV(8, 0)
+/* GCR_ERR_CONTROL register fields */
+#define CM_GCR_ERR_CONTROL_L2_ECC_EN_SHF 1
+#define CM_GCR_ERR_CONTROL_L2_ECC_EN_MSK (_ULCAST_(0x1) << 1)
+#define CM_GCR_ERR_CONTROL_L2_ECC_SUPPORT_SHF 0
+#define CM_GCR_ERR_CONTROL_L2_ECC_SUPPORT_MSK (_ULCAST_(0x1) << 0)
+
/* GCR_ERROR_CAUSE register fields */
#define CM_GCR_ERROR_CAUSE_ERRTYPE_SHF 27
#define CM_GCR_ERROR_CAUSE_ERRTYPE_MSK (_ULCAST_(0x1f) << 27)
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -51,6 +51,7 @@
#include <asm/idle.h>
#include <asm/mips-cm.h>
#include <asm/mips-r2-to-r6-emul.h>
+#include <asm/mips-cm.h>
#include <asm/mipsregs.h>
#include <asm/mipsmtregs.h>
#include <asm/module.h>
@@ -1646,6 +1647,65 @@ __setup("nol2par", nol2parity);
*/
static inline void parity_protection_init(void)
{
+#define ERRCTL_PE 0x80000000
+#define ERRCTL_L2P 0x00800000
+
+ if (mips_cm_revision() >= CM_REV_CM3) {
+ ulong gcr_ectl, cp0_ectl;
+
+ /*
+ * With CM3 systems we need to ensure that the L1 & L2
+ * parity enables are set to the same value, since this
+ * is presumed by the hardware engineers.
+ *
+ * If the user disabled either of L1 or L2 ECC checking,
+ * disable both.
+ */
+ l1parity &= l2parity;
+ l2parity &= l1parity;
+
+ /* Probe L1 ECC support */
+ cp0_ectl = read_c0_ecc();
+ write_c0_ecc(cp0_ectl | ERRCTL_PE);
+ back_to_back_c0_hazard();
+ cp0_ectl = read_c0_ecc();
+
+ /* Probe L2 ECC support */
+ gcr_ectl = read_gcr_err_control();
+
+ if (!(gcr_ectl & CM_GCR_ERR_CONTROL_L2_ECC_SUPPORT_MSK) ||
+ !(cp0_ectl & ERRCTL_PE)) {
+ /*
+ * One of L1 or L2 ECC checking isn't supported,
+ * so we cannot enable either.
+ */
+ l1parity = l2parity = 0;
+ }
+
+ /* Configure L1 ECC checking */
+ if (l1parity)
+ cp0_ectl |= ERRCTL_PE;
+ else
+ cp0_ectl &= ~ERRCTL_PE;
+ write_c0_ecc(cp0_ectl);
+ back_to_back_c0_hazard();
+ WARN_ON(!!(read_c0_ecc() & ERRCTL_PE) != l1parity);
+
+ /* Configure L2 ECC checking */
+ if (l2parity)
+ gcr_ectl |= CM_GCR_ERR_CONTROL_L2_ECC_EN_MSK;
+ else
+ gcr_ectl &= ~CM_GCR_ERR_CONTROL_L2_ECC_EN_MSK;
+ write_gcr_err_control(gcr_ectl);
+ gcr_ectl = read_gcr_err_control();
+ gcr_ectl &= CM_GCR_ERR_CONTROL_L2_ECC_EN_MSK;
+ WARN_ON(!!gcr_ectl != l2parity);
+
+ pr_info("Cache parity protection %sabled\n",
+ l1parity ? "en" : "dis");
+ return;
+ }
+
switch (current_cpu_type()) {
case CPU_24K:
case CPU_34K:
@@ -1656,11 +1716,8 @@ static inline void parity_protection_ini
case CPU_PROAPTIV:
case CPU_P5600:
case CPU_QEMU_GENERIC:
- case CPU_I6400:
case CPU_P6600:
{
-#define ERRCTL_PE 0x80000000
-#define ERRCTL_L2P 0x00800000
unsigned long errctl;
unsigned int l1parity_present, l2parity_present;
Patches currently in stable-queue which might be from paul.burton(a)imgtec.com are
queue-4.9/mips-netlogic-exclude-netlogic-xlp-pic-code-from-xlr-builds.patch
queue-4.9/mips-traps-ensure-l1-l2-ecc-checking-match-for-cm3-systems.patch
queue-4.9/mips-end-asm-function-prologue-macros-with-.insn.patch
This is a note to let you know that I've just added the patch titled
MIPS: init: Ensure reserved memory regions are not added to bootmem
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-init-ensure-reserved-memory-regions-are-not-added-to-bootmem.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com>
Date: Wed, 23 Nov 2016 14:43:44 +0100
Subject: MIPS: init: Ensure reserved memory regions are not added to bootmem
From: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com>
[ Upstream commit e89ef66d7682f031f026eee6bba03c8c2248d2a9 ]
Memories managed through boot_mem_map are generally expected to define
non-crossing areas. However, if part of a larger memory block is marked
as reserved, it would still be added to bootmem allocator as an
available block and could end up being overwritten by the allocator.
Prevent this by explicitly marking the memory as reserved it if exists
in the range used by bootmem allocator.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14608/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/setup.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -551,6 +551,10 @@ static void __init bootmem_init(void)
continue;
default:
/* Not usable memory */
+ if (start > min_low_pfn && end < max_low_pfn)
+ reserve_bootmem(boot_mem_map.map[i].addr,
+ boot_mem_map.map[i].size,
+ BOOTMEM_DEFAULT);
continue;
}
Patches currently in stable-queue which might be from marcin.nowakowski(a)imgtec.com are
queue-4.9/mips-init-ensure-bootmem-does-not-corrupt-reserved-memory.patch
queue-4.9/mips-init-ensure-reserved-memory-regions-are-not-added-to-bootmem.patch
This is a note to let you know that I've just added the patch titled
MIPS: init: Ensure bootmem does not corrupt reserved memory
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-init-ensure-bootmem-does-not-corrupt-reserved-memory.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com>
Date: Wed, 23 Nov 2016 14:43:45 +0100
Subject: MIPS: init: Ensure bootmem does not corrupt reserved memory
From: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com>
[ Upstream commit d9b5b658210f28ed9f70c757d553e679d76e2986 ]
Current init code initialises bootmem allocator with all of the low
memory that it assumes is available, but does not check for reserved
memory block, which can lead to corruption of data that may be stored
there.
Move bootmem's allocation map to a location that does not cross any
reserved regions
Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14609/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/setup.c | 74 +++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 71 insertions(+), 3 deletions(-)
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -153,6 +153,35 @@ void __init detect_memory_region(phys_ad
add_memory_region(start, size, BOOT_MEM_RAM);
}
+bool __init memory_region_available(phys_addr_t start, phys_addr_t size)
+{
+ int i;
+ bool in_ram = false, free = true;
+
+ for (i = 0; i < boot_mem_map.nr_map; i++) {
+ phys_addr_t start_, end_;
+
+ start_ = boot_mem_map.map[i].addr;
+ end_ = boot_mem_map.map[i].addr + boot_mem_map.map[i].size;
+
+ switch (boot_mem_map.map[i].type) {
+ case BOOT_MEM_RAM:
+ if (start >= start_ && start + size <= end_)
+ in_ram = true;
+ break;
+ case BOOT_MEM_RESERVED:
+ if ((start >= start_ && start < end_) ||
+ (start < start_ && start + size >= start_))
+ free = false;
+ break;
+ default:
+ continue;
+ }
+ }
+
+ return in_ram && free;
+}
+
static void __init print_memory_map(void)
{
int i;
@@ -332,11 +361,19 @@ static void __init bootmem_init(void)
#else /* !CONFIG_SGI_IP27 */
+static unsigned long __init bootmap_bytes(unsigned long pages)
+{
+ unsigned long bytes = DIV_ROUND_UP(pages, 8);
+
+ return ALIGN(bytes, sizeof(long));
+}
+
static void __init bootmem_init(void)
{
unsigned long reserved_end;
unsigned long mapstart = ~0UL;
unsigned long bootmap_size;
+ bool bootmap_valid = false;
int i;
/*
@@ -430,11 +467,42 @@ static void __init bootmem_init(void)
#endif
/*
- * Initialize the boot-time allocator with low memory only.
+ * check that mapstart doesn't overlap with any of
+ * memory regions that have been reserved through eg. DTB
*/
- bootmap_size = init_bootmem_node(NODE_DATA(0), mapstart,
- min_low_pfn, max_low_pfn);
+ bootmap_size = bootmap_bytes(max_low_pfn - min_low_pfn);
+
+ bootmap_valid = memory_region_available(PFN_PHYS(mapstart),
+ bootmap_size);
+ for (i = 0; i < boot_mem_map.nr_map && !bootmap_valid; i++) {
+ unsigned long mapstart_addr;
+
+ switch (boot_mem_map.map[i].type) {
+ case BOOT_MEM_RESERVED:
+ mapstart_addr = PFN_ALIGN(boot_mem_map.map[i].addr +
+ boot_mem_map.map[i].size);
+ if (PHYS_PFN(mapstart_addr) < mapstart)
+ break;
+
+ bootmap_valid = memory_region_available(mapstart_addr,
+ bootmap_size);
+ if (bootmap_valid)
+ mapstart = PHYS_PFN(mapstart_addr);
+ break;
+ default:
+ break;
+ }
+ }
+ if (!bootmap_valid)
+ panic("No memory area to place a bootmap bitmap");
+
+ /*
+ * Initialize the boot-time allocator with low memory only.
+ */
+ if (bootmap_size != init_bootmem_node(NODE_DATA(0), mapstart,
+ min_low_pfn, max_low_pfn))
+ panic("Unexpected memory size required for bootmap");
for (i = 0; i < boot_mem_map.nr_map; i++) {
unsigned long start, end;
Patches currently in stable-queue which might be from marcin.nowakowski(a)imgtec.com are
queue-4.9/mips-init-ensure-bootmem-does-not-corrupt-reserved-memory.patch
queue-4.9/mips-init-ensure-reserved-memory-regions-are-not-added-to-bootmem.patch
This is a note to let you know that I've just added the patch titled
MIPS: End asm function prologue macros with .insn
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-end-asm-function-prologue-macros-with-.insn.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Paul Burton <paul.burton(a)imgtec.com>
Date: Mon, 7 Nov 2016 11:14:09 +0000
Subject: MIPS: End asm function prologue macros with .insn
From: Paul Burton <paul.burton(a)imgtec.com>
[ Upstream commit 08889582b8aa0bbc01a1e5a0033b9f98d2e11caa ]
When building a kernel targeting a microMIPS ISA, recent GNU linkers
will fail the link if they cannot determine that the target of a branch
or jump is microMIPS code, with errors such as the following:
mips-img-linux-gnu-ld: arch/mips/built-in.o: .text+0x542c:
Unsupported jump between ISA modes; consider recompiling with
interlinking enabled.
mips-img-linux-gnu-ld: final link failed: Bad value
or:
./arch/mips/include/asm/uaccess.h:1017: warning: JALX to a
non-word-aligned address
Placing anything other than an instruction at the start of a function
written in assembly appears to trigger such errors. In order to prepare
for allowing us to follow function prologue macros with an EXPORT_SYMBOL
invocation, end the prologue macros (LEAD, NESTED & FEXPORT) with a
.insn directive. This ensures that the start of the function is marked
as code, which always makes sense for functions & safely prevents us
from hitting the link errors described above.
Signed-off-by: Paul Burton <paul.burton(a)imgtec.com>
Reviewed-by: Maciej W. Rozycki <macro(a)imgtec.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14508/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/include/asm/asm.h | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/arch/mips/include/asm/asm.h
+++ b/arch/mips/include/asm/asm.h
@@ -54,7 +54,8 @@
.align 2; \
.type symbol, @function; \
.ent symbol, 0; \
-symbol: .frame sp, 0, ra
+symbol: .frame sp, 0, ra; \
+ .insn
/*
* NESTED - declare nested routine entry point
@@ -63,8 +64,9 @@ symbol: .frame sp, 0, ra
.globl symbol; \
.align 2; \
.type symbol, @function; \
- .ent symbol, 0; \
-symbol: .frame sp, framesize, rpc
+ .ent symbol, 0; \
+symbol: .frame sp, framesize, rpc; \
+ .insn
/*
* END - mark end of function
@@ -86,7 +88,7 @@ symbol:
#define FEXPORT(symbol) \
.globl symbol; \
.type symbol, @function; \
-symbol:
+symbol: .insn
/*
* ABS - export absolute symbol
Patches currently in stable-queue which might be from paul.burton(a)imgtec.com are
queue-4.9/mips-netlogic-exclude-netlogic-xlp-pic-code-from-xlr-builds.patch
queue-4.9/mips-traps-ensure-l1-l2-ecc-checking-match-for-cm3-systems.patch
queue-4.9/mips-end-asm-function-prologue-macros-with-.insn.patch
This is a note to let you know that I've just added the patch titled
ixgbe: handle close/suspend race with netif_device_detach/present
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
Date: Fri, 11 Nov 2016 10:07:47 -0800
Subject: ixgbe: handle close/suspend race with netif_device_detach/present
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
[ Upstream commit f7f37e7ff2b9b7eff7fbd035569cab35896869a3 ]
When an interface is part of a namespace it is possible that
ixgbe_close() may be called while __ixgbe_shutdown() is running
which ends up in a double free WARN and/or a BUG in free_msi_irqs().
To handle this situation we extend the rtnl_lock() to protect the
call to netif_device_detach() and ixgbe_clear_interrupt_scheme()
in __ixgbe_shutdown() and check for netif_device_present()
to avoid clearing the interrupts second time in ixgbe_close();
Also extend the rtnl lock in ixgbe_resume() to netif_device_attach().
Signed-off-by: Emil Tantilov <emil.s.tantilov(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6194,7 +6194,8 @@ int ixgbe_close(struct net_device *netde
ixgbe_ptp_stop(adapter);
- ixgbe_close_suspend(adapter);
+ if (netif_device_present(netdev))
+ ixgbe_close_suspend(adapter);
ixgbe_fdir_filter_exit(adapter);
@@ -6239,14 +6240,12 @@ static int ixgbe_resume(struct pci_dev *
if (!err && netif_running(netdev))
err = ixgbe_open(netdev);
- rtnl_unlock();
- if (err)
- return err;
-
- netif_device_attach(netdev);
+ if (!err)
+ netif_device_attach(netdev);
+ rtnl_unlock();
- return 0;
+ return err;
}
#endif /* CONFIG_PM */
@@ -6261,14 +6260,14 @@ static int __ixgbe_shutdown(struct pci_d
int retval = 0;
#endif
+ rtnl_lock();
netif_device_detach(netdev);
- rtnl_lock();
if (netif_running(netdev))
ixgbe_close_suspend(adapter);
- rtnl_unlock();
ixgbe_clear_interrupt_scheme(adapter);
+ rtnl_unlock();
#ifdef CONFIG_PM
retval = pci_save_state(pdev);
Patches currently in stable-queue which might be from emil.s.tantilov(a)intel.com are
queue-4.9/ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
queue-4.9/ixgbe-do-not-disable-fec-from-the-driver.patch
queue-4.9/ixgbe-fix-aer-error-handling.patch
queue-4.9/ixgbe-add-mask-for-64-rss-queues.patch
This is a note to let you know that I've just added the patch titled
ixgbe: Reduce I2C retry count on X550 devices
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ixgbe-reduce-i2c-retry-count-on-x550-devices.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Tony Nguyen <anthony.l.nguyen(a)intel.com>
Date: Thu, 10 Nov 2016 09:57:29 -0800
Subject: ixgbe: Reduce I2C retry count on X550 devices
From: Tony Nguyen <anthony.l.nguyen(a)intel.com>
[ Upstream commit 3f0d646b720d541309b11e190db58086f446f41e ]
A retry count of 10 is likely to run into problems on X550 devices that
have to detect and reset unresponsive CS4227 devices. So, reduce the I2C
retry count to 3 for X550 and above. This should avoid any possible
regressions in existing devices.
Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
@@ -113,7 +113,7 @@ static s32 ixgbe_read_i2c_combined_gener
u16 reg, u16 *val, bool lock)
{
u32 swfw_mask = hw->phy.phy_semaphore_mask;
- int max_retry = 10;
+ int max_retry = 3;
int retry = 0;
u8 csum_byte;
u8 high_bits;
@@ -1764,6 +1764,8 @@ static s32 ixgbe_read_i2c_byte_generic_i
u32 swfw_mask = hw->phy.phy_semaphore_mask;
bool nack = true;
+ if (hw->mac.type >= ixgbe_mac_X550)
+ max_retry = 3;
if (ixgbe_is_sfp_probe(hw, byte_offset, dev_addr))
max_retry = IXGBE_SFP_DETECT_RETRIES;
Patches currently in stable-queue which might be from anthony.l.nguyen(a)intel.com are
queue-4.9/ixgbe-reduce-i2c-retry-count-on-x550-devices.patch
queue-4.9/ixgbe-fix-reporting-of-100mb-capability.patch
This is a note to let you know that I've just added the patch titled
ixgbe: fix AER error handling
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ixgbe-fix-aer-error-handling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
Date: Wed, 16 Nov 2016 09:48:02 -0800
Subject: ixgbe: fix AER error handling
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
[ Upstream commit 126db13fa0e6d05c9f94e0125f61e773bd5ab079 ]
Make sure that we free the IRQs in ixgbe_io_error_detected() when
responding to an PCIe AER error and also restore them when the
interface recovers from it.
Previously it was possible to trigger BUG_ON() check in free_msix_irqs()
in the case where we call ixgbe_remove() after a failed recovery from
AER error because the interrupts were not freed.
Signed-off-by: Emil Tantilov <emil.s.tantilov(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -10027,7 +10027,7 @@ skip_bad_vf_detection:
}
if (netif_running(netdev))
- ixgbe_down(adapter);
+ ixgbe_close_suspend(adapter);
if (!test_and_set_bit(__IXGBE_DISABLED, &adapter->state))
pci_disable_device(pdev);
@@ -10097,10 +10097,12 @@ static void ixgbe_io_resume(struct pci_d
}
#endif
+ rtnl_lock();
if (netif_running(netdev))
- ixgbe_up(adapter);
+ ixgbe_open(netdev);
netif_device_attach(netdev);
+ rtnl_unlock();
}
static const struct pci_error_handlers ixgbe_err_handler = {
Patches currently in stable-queue which might be from emil.s.tantilov(a)intel.com are
queue-4.9/ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
queue-4.9/ixgbe-do-not-disable-fec-from-the-driver.patch
queue-4.9/ixgbe-fix-aer-error-handling.patch
queue-4.9/ixgbe-add-mask-for-64-rss-queues.patch
This is a note to let you know that I've just added the patch titled
ixgbe: do not disable FEC from the driver
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ixgbe-do-not-disable-fec-from-the-driver.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
Date: Wed, 28 Sep 2016 16:01:48 -0700
Subject: ixgbe: do not disable FEC from the driver
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
[ Upstream commit 1fe954b2097bb907b4578e6a74e4c1d23785a601 ]
FEC is configured by the NVM and the driver should not be
overriding it.
Signed-off-by: Emil Tantilov <emil.s.tantilov(a)intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -1932,8 +1932,6 @@ static s32 ixgbe_setup_kr_speed_x550em(s
return status;
reg_val |= IXGBE_KRM_LINK_CTRL_1_TETH_AN_ENABLE;
- reg_val &= ~(IXGBE_KRM_LINK_CTRL_1_TETH_AN_FEC_REQ |
- IXGBE_KRM_LINK_CTRL_1_TETH_AN_CAP_FEC);
reg_val &= ~(IXGBE_KRM_LINK_CTRL_1_TETH_AN_CAP_KR |
IXGBE_KRM_LINK_CTRL_1_TETH_AN_CAP_KX);
Patches currently in stable-queue which might be from emil.s.tantilov(a)intel.com are
queue-4.9/ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
queue-4.9/ixgbe-do-not-disable-fec-from-the-driver.patch
queue-4.9/ixgbe-fix-aer-error-handling.patch
queue-4.9/ixgbe-add-mask-for-64-rss-queues.patch
This is a note to let you know that I've just added the patch titled
ixgbe: Fix reporting of 100Mb capability
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ixgbe-fix-reporting-of-100mb-capability.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Tony Nguyen <anthony.l.nguyen(a)intel.com>
Date: Thu, 10 Nov 2016 16:00:33 -0800
Subject: ixgbe: Fix reporting of 100Mb capability
From: Tony Nguyen <anthony.l.nguyen(a)intel.com>
[ Upstream commit f215266470dfe86196a31fe0725a86cea77f9a18 ]
BaseT adapters that are capable of supporting 100Mb are not reporting this
capability. This patch corrects the reporting so that 100Mb is shown as
supported on those adapters.
Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -199,7 +199,7 @@ static int ixgbe_get_settings(struct net
if (supported_link & IXGBE_LINK_SPEED_100_FULL)
ecmd->supported |= ixgbe_isbackplane(hw->phy.media_type) ?
SUPPORTED_1000baseKX_Full :
- SUPPORTED_1000baseT_Full;
+ SUPPORTED_100baseT_Full;
/* default advertised speed if phy.autoneg_advertised isn't set */
ecmd->advertising = ecmd->supported;
Patches currently in stable-queue which might be from anthony.l.nguyen(a)intel.com are
queue-4.9/ixgbe-reduce-i2c-retry-count-on-x550-devices.patch
queue-4.9/ixgbe-fix-reporting-of-100mb-capability.patch
This is a note to let you know that I've just added the patch titled
igb: reset the PHY before reading the PHY ID
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
igb-reset-the-phy-before-reading-the-phy-id.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Aaron Sierra <asierra(a)xes-inc.com>
Date: Tue, 29 Nov 2016 10:03:56 -0600
Subject: igb: reset the PHY before reading the PHY ID
From: Aaron Sierra <asierra(a)xes-inc.com>
[ Upstream commit 182785335447957409282ca745aa5bc3968facee ]
Several people have reported firmware leaving the I210/I211 PHY's page
select register set to something other than the default of zero. This
causes the first accesses, PHY_IDx register reads, to access something
else, resulting in device probe failure:
igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
igb: Copyright (c) 2007-2014 Intel Corporation.
igb: probe of 0000:01:00.0 failed with error -2
This problem began for them after a previous patch I submitted was
applied:
commit 2a3cdead8b408351fa1e3079b220fa331480ffbc
Author: Aaron Sierra <asierra(a)xes-inc.com>
Date: Tue Nov 3 12:37:09 2015 -0600
igb: Remove GS40G specific defines/functions
I personally experienced this problem after attempting to PXE boot from
I210 devices using this firmware:
Intel(R) Boot Agent GE v1.5.78
Copyright (C) 1997-2014, Intel Corporation
Resetting the PHY before reading from it, ensures the page select
register is in its default state and doesn't make assumptions about
the PHY's register set before the PHY has been probed.
Cc: Matwey V. Kornilov <matwey(a)sai.msu.ru>
Cc: Chris Arges <carges(a)vectranetworks.com>
Cc: Jochen Henneberg <jh(a)henneberg-systemdesign.com>
Signed-off-by: Aaron Sierra <asierra(a)xes-inc.com>
Tested-by: Matwey V. Kornilov <matwey(a)sai.msu.ru>
Tested-by: Chris J Arges <christopherarges(a)gmail.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -245,6 +245,17 @@ static s32 igb_init_phy_params_82575(str
hw->bus.func = (rd32(E1000_STATUS) & E1000_STATUS_FUNC_MASK) >>
E1000_STATUS_FUNC_SHIFT;
+ /* Make sure the PHY is in a good state. Several people have reported
+ * firmware leaving the PHY's page select register set to something
+ * other than the default of zero, which causes the PHY ID read to
+ * access something other than the intended register.
+ */
+ ret_val = hw->phy.ops.reset(hw);
+ if (ret_val) {
+ hw_dbg("Error resetting the PHY.\n");
+ goto out;
+ }
+
/* Set phy->phy_addr and phy->id. */
igb_write_phy_reg_82580(hw, I347AT4_PAGE_SELECT, 0);
ret_val = igb_get_phy_id_82575(hw);
Patches currently in stable-queue which might be from asierra(a)xes-inc.com are
queue-4.9/igb-reset-the-phy-before-reading-the-phy-id.patch
This is a note to let you know that I've just added the patch titled
ixgbe: add mask for 64 RSS queues
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ixgbe-add-mask-for-64-rss-queues.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
Date: Fri, 4 Nov 2016 14:03:03 -0700
Subject: ixgbe: add mask for 64 RSS queues
From: Emil Tantilov <emil.s.tantilov(a)intel.com>
[ Upstream commit 2bf1a87b903bd81b1448a1cef73de59fb6c4d340 ]
The indirection table was reported incorrectly for X550 and newer
where we can support up to 64 RSS queues.
Reported-by Krishneil Singh <krishneil.k.singh(a)intel.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
@@ -308,6 +308,7 @@ static void ixgbe_cache_ring_register(st
ixgbe_cache_ring_rss(adapter);
}
+#define IXGBE_RSS_64Q_MASK 0x3F
#define IXGBE_RSS_16Q_MASK 0xF
#define IXGBE_RSS_8Q_MASK 0x7
#define IXGBE_RSS_4Q_MASK 0x3
@@ -604,6 +605,7 @@ static bool ixgbe_set_sriov_queues(struc
**/
static bool ixgbe_set_rss_queues(struct ixgbe_adapter *adapter)
{
+ struct ixgbe_hw *hw = &adapter->hw;
struct ixgbe_ring_feature *f;
u16 rss_i;
@@ -612,7 +614,11 @@ static bool ixgbe_set_rss_queues(struct
rss_i = f->limit;
f->indices = rss_i;
- f->mask = IXGBE_RSS_16Q_MASK;
+
+ if (hw->mac.type < ixgbe_mac_X550)
+ f->mask = IXGBE_RSS_16Q_MASK;
+ else
+ f->mask = IXGBE_RSS_64Q_MASK;
/* disable ATR by default, it will be configured below */
adapter->flags &= ~IXGBE_FLAG_FDIR_HASH_CAPABLE;
Patches currently in stable-queue which might be from emil.s.tantilov(a)intel.com are
queue-4.9/ixgbe-handle-close-suspend-race-with-netif_device_detach-present.patch
queue-4.9/ixgbe-do-not-disable-fec-from-the-driver.patch
queue-4.9/ixgbe-fix-aer-error-handling.patch
queue-4.9/ixgbe-add-mask-for-64-rss-queues.patch
This is a note to let you know that I've just added the patch titled
ixgbe: Configure advertised speeds correctly for KR/KX backplane
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ixgbe-configure-advertised-speeds-correctly-for-kr-kx-backplane.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Don Skidmore <donald.c.skidmore(a)intel.com>
Date: Tue, 13 Dec 2016 20:34:51 -0500
Subject: ixgbe: Configure advertised speeds correctly for KR/KX backplane
From: Don Skidmore <donald.c.skidmore(a)intel.com>
[ Upstream commit 54f6d4c42451dbd2cc7e0f0bd8fc3eddcab511fe ]
This patch ensures that the advertised link speeds are configured
for X553 KR/KX backplane. Without this patch the link remains at
1G when resuming from low power after being downshifted by LPLU.
Signed-off-by: Don Skidmore <donald.c.skidmore(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -1995,12 +1995,11 @@ static s32 ixgbe_setup_kx4_x550em(struct
/**
* ixgbe_setup_kr_x550em - Configure the KR PHY
* @hw: pointer to hardware structure
- *
- * Configures the integrated KR PHY for X550EM_x.
**/
static s32 ixgbe_setup_kr_x550em(struct ixgbe_hw *hw)
{
- if (hw->mac.type != ixgbe_mac_X550EM_x)
+ /* leave link alone for 2.5G */
+ if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_2_5GB_FULL)
return 0;
return ixgbe_setup_kr_speed_x550em(hw, hw->phy.autoneg_advertised);
Patches currently in stable-queue which might be from donald.c.skidmore(a)intel.com are
queue-4.9/ixgbe-configure-advertised-speeds-correctly-for-kr-kx-backplane.patch
This is a note to let you know that I've just added the patch titled
igb: Fix hw_dbg logging in igb_update_flash_i210
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
igb-fix-hw_dbg-logging-in-igb_update_flash_i210.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Hannu Lounento <hannu.lounento(a)ge.com>
Date: Mon, 2 Jan 2017 18:26:06 +0100
Subject: igb: Fix hw_dbg logging in igb_update_flash_i210
From: Hannu Lounento <hannu.lounento(a)ge.com>
[ Upstream commit 76ed5a8f47476e4984cc8c0c1bc4cee62650f7fd ]
Fix an if statement with hw_dbg lines where the logic was inverted with
regards to the corresponding return value used in the if statement.
Signed-off-by: Hannu Lounento <hannu.lounento(a)ge.com>
Signed-off-by: Peter Senna Tschudin <peter.senna(a)collabora.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/e1000_i210.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/intel/igb/e1000_i210.c
+++ b/drivers/net/ethernet/intel/igb/e1000_i210.c
@@ -699,9 +699,9 @@ static s32 igb_update_flash_i210(struct
ret_val = igb_pool_flash_update_done_i210(hw);
if (ret_val)
- hw_dbg("Flash update complete\n");
- else
hw_dbg("Flash update time out\n");
+ else
+ hw_dbg("Flash update complete\n");
out:
return ret_val;
Patches currently in stable-queue which might be from hannu.lounento(a)ge.com are
queue-4.9/igb-fix-hw_dbg-logging-in-igb_update_flash_i210.patch
This is a note to let you know that I've just added the patch titled
gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Tue, 3 Jan 2017 17:00:27 +0530
Subject: gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit 4b0ea93f250afc6c1128e201b0a8a115ae613e47 ]
Here, pci_iomap can fail, handle this case and return -ENOMEM.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1483443027-13444-1-git-send-em…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -145,6 +145,8 @@ static int mga_vram_init(struct mga_devi
}
mem = pci_iomap(mdev->dev->pdev, 0, 0);
+ if (!mem)
+ return -ENOMEM;
mdev->mc.vram_size = mga_probe_vram(mdev, mem);
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.9/gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
queue-4.9/media-imon-fix-null-ptr-deref-in-imon_probe.patch
queue-4.9/drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
This is a note to let you know that I've just added the patch titled
igb: close/suspend race in netif_device_detach
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
igb-close-suspend-race-in-netif_device_detach.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Todd Fujinaka <todd.fujinaka(a)intel.com>
Date: Tue, 15 Nov 2016 08:54:26 -0800
Subject: igb: close/suspend race in netif_device_detach
From: Todd Fujinaka <todd.fujinaka(a)intel.com>
[ Upstream commit 9474933caf21a4cb5147223dca1551f527aaac36 ]
Similar to ixgbe, when an interface is part of a namespace it is
possible that igb_close() may be called while __igb_shutdown() is
running which ends up in a double free WARN and/or a BUG in
free_msi_irqs().
Extend the rtnl_lock() to protect the call to netif_device_detach() and
igb_clear_interrupt_scheme() in __igb_shutdown() and check for
netif_device_present() to avoid calling igb_clear_interrupt_scheme() a
second time in igb_close().
Also extend the rtnl lock in igb_resume() to netif_device_attach().
Signed-off-by: Todd Fujinaka <todd.fujinaka(a)intel.com>
Acked-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3271,7 +3271,9 @@ static int __igb_close(struct net_device
int igb_close(struct net_device *netdev)
{
- return __igb_close(netdev, false);
+ if (netif_device_present(netdev))
+ return __igb_close(netdev, false);
+ return 0;
}
/**
@@ -7548,6 +7550,7 @@ static int __igb_shutdown(struct pci_dev
int retval = 0;
#endif
+ rtnl_lock();
netif_device_detach(netdev);
if (netif_running(netdev))
@@ -7556,6 +7559,7 @@ static int __igb_shutdown(struct pci_dev
igb_ptp_suspend(adapter);
igb_clear_interrupt_scheme(adapter);
+ rtnl_unlock();
#ifdef CONFIG_PM
retval = pci_save_state(pdev);
@@ -7674,16 +7678,15 @@ static int igb_resume(struct device *dev
wr32(E1000_WUS, ~0);
- if (netdev->flags & IFF_UP) {
- rtnl_lock();
+ rtnl_lock();
+ if (!err && netif_running(netdev))
err = __igb_open(netdev, true);
- rtnl_unlock();
- if (err)
- return err;
- }
- netif_device_attach(netdev);
- return 0;
+ if (!err)
+ netif_device_attach(netdev);
+ rtnl_unlock();
+
+ return err;
}
static int igb_runtime_idle(struct device *dev)
Patches currently in stable-queue which might be from todd.fujinaka(a)intel.com are
queue-4.9/igb-close-suspend-race-in-netif_device_detach.patch
This is a note to let you know that I've just added the patch titled
extcon: Remove potential problem when calling extcon_register_notifier()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
extcon-remove-potential-problem-when-calling-extcon_register_notifier.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Chanwoo Choi <cw00.choi(a)samsung.com>
Date: Mon, 19 Dec 2016 21:02:33 +0900
Subject: extcon: Remove potential problem when calling extcon_register_notifier()
From: Chanwoo Choi <cw00.choi(a)samsung.com>
[ Upstream commit 01b4c9a1ae07a25d208cad0da7dd288007a22984 ]
This patch removes the potential problem of extcon_register_notifier()
when edev parameter is NULL. When edev is NULL, this function returns
the first extcon device which includes the sepecific external connector
of second paramter. But, it don't guarantee the same operation in all cases.
To remove this confusion and potential problem, this patch fixes it.
Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/extcon/extcon.c | 35 ++++++++---------------------------
1 file changed, 8 insertions(+), 27 deletions(-)
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -906,35 +906,16 @@ int extcon_register_notifier(struct extc
unsigned long flags;
int ret, idx = -EINVAL;
- if (!nb)
+ if (!edev || !nb)
return -EINVAL;
- if (edev) {
- idx = find_cable_index_by_id(edev, id);
- if (idx < 0)
- return idx;
-
- spin_lock_irqsave(&edev->lock, flags);
- ret = raw_notifier_chain_register(&edev->nh[idx], nb);
- spin_unlock_irqrestore(&edev->lock, flags);
- } else {
- struct extcon_dev *extd;
-
- mutex_lock(&extcon_dev_list_lock);
- list_for_each_entry(extd, &extcon_dev_list, entry) {
- idx = find_cable_index_by_id(extd, id);
- if (idx >= 0)
- break;
- }
- mutex_unlock(&extcon_dev_list_lock);
-
- if (idx >= 0) {
- edev = extd;
- return extcon_register_notifier(extd, id, nb);
- } else {
- ret = -ENODEV;
- }
- }
+ idx = find_cable_index_by_id(edev, id);
+ if (idx < 0)
+ return idx;
+
+ spin_lock_irqsave(&edev->lock, flags);
+ ret = raw_notifier_chain_register(&edev->nh[idx], nb);
+ spin_unlock_irqrestore(&edev->lock, flags);
return ret;
}
Patches currently in stable-queue which might be from cw00.choi(a)samsung.com are
queue-4.9/extcon-remove-potential-problem-when-calling-extcon_register_notifier.patch
queue-4.9/extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
This is a note to let you know that I've just added the patch titled
fm10k: request reset when mbx->state changes
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fm10k-request-reset-when-mbx-state-changes.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Ngai-Mint Kwan <ngai-mint.kwan(a)intel.com>
Date: Wed, 2 Nov 2016 16:44:46 -0700
Subject: fm10k: request reset when mbx->state changes
From: Ngai-Mint Kwan <ngai-mint.kwan(a)intel.com>
[ Upstream commit 2f3fc1e6200309ccf87f61dea56e57e563c4f800 ]
Multiple IES API resets can cause a race condition where the mailbox
interrupt request bits can be cleared before being handled. This can
leave certain mailbox messages from the PF to be untreated and the PF
will enter in some inactive state. If this situation occurs, the IES API
will initiate a mailbox version reset which, then, trigger a mailbox
state change. Once this mailbox transition occurs (from OPEN to CONNECT
state), a request for reset will be returned.
This ensures that PF will undergo a reset whenever IES API encounters an
unknown global mailbox interrupt event or whenever the IES API
terminates.
Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan(a)intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 10 +++++++---
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 +++++-
2 files changed, 12 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
@@ -2011,9 +2011,10 @@ static void fm10k_sm_mbx_create_reply(st
* function can also be used to respond to an error as the connection
* resetting would also be a means of dealing with errors.
**/
-static void fm10k_sm_mbx_process_reset(struct fm10k_hw *hw,
- struct fm10k_mbx_info *mbx)
+static s32 fm10k_sm_mbx_process_reset(struct fm10k_hw *hw,
+ struct fm10k_mbx_info *mbx)
{
+ s32 err = 0;
const enum fm10k_mbx_state state = mbx->state;
switch (state) {
@@ -2026,6 +2027,7 @@ static void fm10k_sm_mbx_process_reset(s
case FM10K_STATE_OPEN:
/* flush any incomplete work */
fm10k_sm_mbx_connect_reset(mbx);
+ err = FM10K_ERR_RESET_REQUESTED;
break;
case FM10K_STATE_CONNECT:
/* Update remote value to match local value */
@@ -2035,6 +2037,8 @@ static void fm10k_sm_mbx_process_reset(s
}
fm10k_sm_mbx_create_reply(hw, mbx, mbx->tail);
+
+ return err;
}
/**
@@ -2115,7 +2119,7 @@ static s32 fm10k_sm_mbx_process(struct f
switch (FM10K_MSG_HDR_FIELD_GET(mbx->mbx_hdr, SM_VER)) {
case 0:
- fm10k_sm_mbx_process_reset(hw, mbx);
+ err = fm10k_sm_mbx_process_reset(hw, mbx);
break;
case FM10K_SM_MBX_VERSION:
err = fm10k_sm_mbx_process_version_1(hw, mbx);
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -1144,6 +1144,7 @@ static irqreturn_t fm10k_msix_mbx_pf(int
struct fm10k_hw *hw = &interface->hw;
struct fm10k_mbx_info *mbx = &hw->mbx;
u32 eicr;
+ s32 err = 0;
/* unmask any set bits related to this interrupt */
eicr = fm10k_read_reg(hw, FM10K_EICR);
@@ -1159,12 +1160,15 @@ static irqreturn_t fm10k_msix_mbx_pf(int
/* service mailboxes */
if (fm10k_mbx_trylock(interface)) {
- mbx->ops.process(hw, mbx);
+ err = mbx->ops.process(hw, mbx);
/* handle VFLRE events */
fm10k_iov_event(interface);
fm10k_mbx_unlock(interface);
}
+ if (err == FM10K_ERR_RESET_REQUESTED)
+ interface->flags |= FM10K_FLAG_RESET_REQUESTED;
+
/* if switch toggled state we should reset GLORTs */
if (eicr & FM10K_EICR_SWITCHNOTREADY) {
/* force link down for at least 4 seconds */
Patches currently in stable-queue which might be from ngai-mint.kwan(a)intel.com are
queue-4.9/fm10k-request-reset-when-mbx-state-changes.patch
This is a note to let you know that I've just added the patch titled
drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Wed, 21 Dec 2016 11:00:12 +0530
Subject: drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit 1ae0d5af347df224a6e76334683f13a96d915a44 ]
Here, If devm_ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference. This error check
will avoid NULL pointer dereference.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Acked-by: Vincent Abriou <vincent.abriou(a)st.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/sti/sti_vtg.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -429,6 +429,10 @@ static int vtg_probe(struct platform_dev
return -ENOMEM;
}
vtg->regs = devm_ioremap_nocache(dev, res->start, resource_size(res));
+ if (!vtg->regs) {
+ DRM_ERROR("failed to remap I/O memory\n");
+ return -ENOMEM;
+ }
np = of_parse_phandle(pdev->dev.of_node, "st,slave", 0);
if (np) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.9/gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
queue-4.9/media-imon-fix-null-ptr-deref-in-imon_probe.patch
queue-4.9/drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
This is a note to let you know that I've just added the patch titled
extcon: palmas: Check the parent instance to prevent the NULL
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Roger Quadros <rogerq(a)ti.com>
Date: Thu, 8 Dec 2016 10:45:31 +0200
Subject: extcon: palmas: Check the parent instance to prevent the NULL
From: Roger Quadros <rogerq(a)ti.com>
[ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ]
extcon-palmas must be child of palmas and expects parent's
drvdata to be valid. Check for non NULL parent drvdata and
fail if it is NULL. Not doing so will result in a NULL
pointer dereference later in the probe() parent drvdata
is NULL (e.g. misplaced extcon-palmas node in device tree).
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/extcon/extcon-palmas.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -190,6 +190,11 @@ static int palmas_usb_probe(struct platf
struct palmas_usb *palmas_usb;
int status;
+ if (!palmas) {
+ dev_err(&pdev->dev, "failed to get valid parent\n");
+ return -EINVAL;
+ }
+
palmas_usb = devm_kzalloc(&pdev->dev, sizeof(*palmas_usb), GFP_KERNEL);
if (!palmas_usb)
return -ENOMEM;
Patches currently in stable-queue which might be from rogerq(a)ti.com are
queue-4.9/extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
This is a note to let you know that I've just added the patch titled
drm/omap: panel-sony-acx565akm.c: Add MODULE_ALIAS
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-omap-panel-sony-acx565akm.c-add-module_alias.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Jarkko Nikula <jarkko.nikula(a)bitmer.com>
Date: Tue, 27 Dec 2016 22:12:16 +0200
Subject: drm/omap: panel-sony-acx565akm.c: Add MODULE_ALIAS
From: Jarkko Nikula <jarkko.nikula(a)bitmer.com>
[ Upstream commit 42f7f3c4811b3149253ecf2e133832c969884466 ]
Add module alias for Sony ACX565AKM LCD panel. This makes it probe on Nokia
N900 when panel driver is built as a module.
Signed-off-by: Jarkko Nikula <jarkko.nikula(a)bitmer.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
@@ -912,6 +912,7 @@ static struct spi_driver acx565akm_drive
module_spi_driver(acx565akm_driver);
+MODULE_ALIAS("spi:sony,acx565akm");
MODULE_AUTHOR("Nokia Corporation");
MODULE_DESCRIPTION("acx565akm LCD Driver");
MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from jarkko.nikula(a)bitmer.com are
queue-4.9/drm-omap-panel-sony-acx565akm.c-add-module_alias.patch
This is a note to let you know that I've just added the patch titled
backlight: lcd: Fix race condition during register
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
backlight-lcd-fix-race-condition-during-register.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Date: Wed, 6 Jul 2016 19:33:05 +0200
Subject: backlight: lcd: Fix race condition during register
From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
[ Upstream commit cc21942bce652d1a92dae85b785378256e1df1f7 ]
Once device_register is called for a device its attributes might be
accessed. As the callbacks of a lcd device's attributes make use of the
lcd_ops, the respective member must be setup before calling
device_register.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/backlight/lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/video/backlight/lcd.c
+++ b/drivers/video/backlight/lcd.c
@@ -226,6 +226,8 @@ struct lcd_device *lcd_device_register(c
dev_set_name(&new_ld->dev, "%s", name);
dev_set_drvdata(&new_ld->dev, devdata);
+ new_ld->ops = ops;
+
rc = device_register(&new_ld->dev);
if (rc) {
put_device(&new_ld->dev);
@@ -238,8 +240,6 @@ struct lcd_device *lcd_device_register(c
return ERR_PTR(rc);
}
- new_ld->ops = ops;
-
return new_ld;
}
EXPORT_SYMBOL(lcd_device_register);
Patches currently in stable-queue which might be from u.kleine-koenig(a)pengutronix.de are
queue-4.9/backlight-lcd-fix-race-condition-during-register.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: fix QCA Rome suspend/resume
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-btusb-fix-qca-rome-suspend-resume.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fd865802c66bc451dc515ed89360f84376ce1a56 Mon Sep 17 00:00:00 2001
From: Leif Liddy <leif.linux(a)gmail.com>
Date: Sat, 8 Jul 2017 20:55:32 +0200
Subject: Bluetooth: btusb: fix QCA Rome suspend/resume
From: Leif Liddy <leif.linux(a)gmail.com>
commit fd865802c66bc451dc515ed89360f84376ce1a56 upstream.
There's been numerous reported instances where BTUSB_QCA_ROME
bluetooth controllers stop functioning upon resume from suspend. These
devices seem to be losing power during suspend. Patch will detect a status
change on resume and perform a reset.
Signed-off-by: Leif Liddy <leif.linux(a)gmail.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Cc: Kai Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2925,6 +2925,12 @@ static int btusb_probe(struct usb_interf
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
+
+ /* QCA Rome devices lose their updated firmware over suspend,
+ * but the USB hub doesn't notice any status change.
+ * Explicitly request a device reset on resume.
+ */
+ set_bit(BTUSB_RESET_RESUME, &data->flags);
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
Patches currently in stable-queue which might be from leif.linux(a)gmail.com are
queue-4.9/bluetooth-btusb-fix-qca-rome-suspend-resume.patch
This is a note to let you know that I've just added the patch titled
backlight: adp5520: Fix error handling in adp5520_bl_probe()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
backlight-adp5520-fix-error-handling-in-adp5520_bl_probe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 9 Jul 2016 01:19:51 +0300
Subject: backlight: adp5520: Fix error handling in adp5520_bl_probe()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit 0eb3fba8c68275f0122f65f7316efaaf86448016 ]
If adp5520_bl_setup() fails, sysfs group left unremoved.
By the way, fix overcomplicated assignement of error code.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Acked-by: Michael Hennerich <michael.hennerich(a)analog.com>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/backlight/adp5520_bl.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/video/backlight/adp5520_bl.c
+++ b/drivers/video/backlight/adp5520_bl.c
@@ -332,10 +332,18 @@ static int adp5520_bl_probe(struct platf
}
platform_set_drvdata(pdev, bl);
- ret |= adp5520_bl_setup(bl);
+ ret = adp5520_bl_setup(bl);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to setup\n");
+ if (data->pdata->en_ambl_sens)
+ sysfs_remove_group(&bl->dev.kobj,
+ &adp5520_bl_attr_group);
+ return ret;
+ }
+
backlight_update_status(bl);
- return ret;
+ return 0;
}
static int adp5520_bl_remove(struct platform_device *pdev)
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.9/backlight-adp5520-fix-error-handling-in-adp5520_bl_probe.patch
This is a note to let you know that I've just added the patch titled
ata: SATA_HIGHBANK should depend on HAS_DMA
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ata-sata_highbank-should-depend-on-has_dma.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Tue, 3 Jan 2017 19:09:45 +0100
Subject: ata: SATA_HIGHBANK should depend on HAS_DMA
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit 2a736e0585e585c2566b5119af8381910a170e44 ]
If NO_DMA=y:
ERROR: "bad_dma_ops" [drivers/ata/sata_highbank.ko] undefined!
Add a dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -345,6 +345,7 @@ config SATA_DWC_VDEBUG
config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
+ depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
This option enables support for the Calxeda Highbank SoC's
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.9/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.9/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.9/ata-ata_bmdma-should-depend-on-has_dma.patch
This is a note to let you know that I've just added the patch titled
ata: SATA_MV should depend on HAS_DMA
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ata-sata_mv-should-depend-on-has_dma.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Tue, 3 Jan 2017 19:09:44 +0100
Subject: ata: SATA_MV should depend on HAS_DMA
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit 62989cebd367a1aae1e009e1a5b1ec046a4c8fdc ]
If NO_DMA=y:
ERROR: "dma_pool_alloc" [drivers/ata/sata_mv.ko] undefined!
ERROR: "dmam_pool_create" [drivers/ata/sata_mv.ko] undefined!
ERROR: "dma_pool_free" [drivers/ata/sata_mv.ko] undefined!
Add a dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -355,6 +355,7 @@ config SATA_HIGHBANK
config SATA_MV
tristate "Marvell SATA support"
+ depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.9/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.9/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.9/ata-ata_bmdma-should-depend-on-has_dma.patch
This is a note to let you know that I've just added the patch titled
ata: ATA_BMDMA should depend on HAS_DMA
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ata-ata_bmdma-should-depend-on-has_dma.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Tue, 3 Jan 2017 19:09:46 +0100
Subject: ata: ATA_BMDMA should depend on HAS_DMA
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit 7bc7ab1e63dfe004931502f90ce7020e375623da ]
If NO_DMA=y:
ERROR: "dmam_alloc_coherent" [drivers/ata/libata.ko] undefined!
Add a dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -289,6 +289,7 @@ config SATA_SX4
config ATA_BMDMA
bool "ATA BMDMA support"
+ depends on HAS_DMA
default y
help
This option adds support for SFF ATA controllers with BMDMA
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.9/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.9/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.9/ata-ata_bmdma-should-depend-on-has_dma.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP2+: Fix init for multiple quirks for the same SoC
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 11:08:20 -0800
Subject: ARM: OMAP2+: Fix init for multiple quirks for the same SoC
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit 6e613ebf4405fc09e2a8c16ed193b47f80a3cbed ]
It's possible that there are multiple quirks that need to be initialized
for the same SoC. Fix the issue by not returning on the first match.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap2/pdata-quirks.c | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -600,7 +600,6 @@ static void pdata_quirks_check(struct pd
if (of_machine_is_compatible(quirks->compatible)) {
if (quirks->fn)
quirks->fn();
- break;
}
quirks++;
}
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: NS2: reserve memory for Nitro firmware
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-dts-ns2-reserve-memory-for-nitro-firmware.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Jon Mason <jon.mason(a)broadcom.com>
Date: Mon, 5 Dec 2016 18:12:21 -0500
Subject: arm64: dts: NS2: reserve memory for Nitro firmware
From: Jon Mason <jon.mason(a)broadcom.com>
[ Upstream commit 0cc878d678444392ca2a31350f89f489593ef5bb ]
Nitro firmware is loaded into memory by the bootloader at a specific
location. Set this memory range aside to prevent the kernel from using
it.
Signed-off-by: Jon Mason <jon.mason(a)broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -30,6 +30,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+/memreserve/ 0x81000000 0x00200000;
+
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/bcm-ns2.h>
Patches currently in stable-queue which might be from jon.mason(a)broadcom.com are
queue-4.9/arm64-dts-ns2-reserve-memory-for-nitro-firmware.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix omap3 off mode pull defines
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-fix-omap3-off-mode-pull-defines.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 11:07:18 -0800
Subject: ARM: dts: Fix omap3 off mode pull defines
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit d97556c8012015901a3ce77f46960078139cd79d ]
We need to also have OFFPULLUDENABLE bit set to use the off mode pull values.
Otherwise the line is pulled down internally if no external pull exists.
This is has some documentation at:
http://processors.wiki.ti.com/index.php/Optimizing_OMAP35x_and_AM/DM37x_OFF…
Note that the value is still glitchy during off mode transitions as documented
in spz319f.pdf "Advisory 1.45". It's best to use external pulls instead of
relying on the internal ones for off mode and even then anything pulled up
will get driven down momentarily on off mode restore for GPIO banks other
than bank1.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/dt-bindings/pinctrl/omap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -45,8 +45,8 @@
#define PIN_OFF_NONE 0
#define PIN_OFF_OUTPUT_HIGH (OFF_EN | OFFOUT_EN | OFFOUT_VAL)
#define PIN_OFF_OUTPUT_LOW (OFF_EN | OFFOUT_EN)
-#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFF_PULL_EN | OFF_PULL_UP)
-#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFF_PULL_EN)
+#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFFOUT_EN | OFF_PULL_EN | OFF_PULL_UP)
+#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFFOUT_EN | OFF_PULL_EN)
#define PIN_OFF_WAKEUPENABLE WAKEUP_EN
/*
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: omap5-uevm: Allow bootloader to configure USB Ethernet MAC
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 08:37:02 -0800
Subject: ARM: dts: omap5-uevm: Allow bootloader to configure USB Ethernet MAC
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit e13a22a406f20322651b8c0847f4210bdef246d1 ]
Note that with 9730 the wiring is different compared to 9514 found on
beagleboard xm for example.
On beagleboard xm we have:
/sys/bus/usb/devices/1-2 hub
/sys/bus/usb/devices/1-2.1 9514
While on omap5-uevm we have:
/sys/bus/usb/devices/1-2 hub
/sys/bus/usb/devices/1-3 9730
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/omap5-uevm.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -18,6 +18,10 @@
reg = <0 0x80000000 0 0x7f000000>; /* 2032 MB */
};
+ aliases {
+ ethernet = ðernet;
+ };
+
leds {
compatible = "gpio-leds";
led1 {
@@ -72,6 +76,23 @@
>;
};
+&usbhsehci {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@2 {
+ compatible = "usb424,3503";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ ethernet: usbether@3 {
+ compatible = "usb424,9730";
+ reg = <3>;
+ };
+};
+
&wlcore {
compatible = "ti,wl1837";
};
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix compatible for ti81xx uarts for 8250
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 11:17:30 -0800
Subject: ARM: dts: Fix compatible for ti81xx uarts for 8250
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit f62280efe8934a1275fd148ef302d1afec8cd3df ]
When using 8250_omap driver, we need to specify the right
compatible value for the UART to work on dm814x and dm816x.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/dm814x.dtsi | 6 +++---
arch/arm/boot/dts/dm816x.dtsi | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -252,7 +252,7 @@
};
uart1: uart@20000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart1";
reg = <0x20000 0x2000>;
clock-frequency = <48000000>;
@@ -262,7 +262,7 @@
};
uart2: uart@22000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart2";
reg = <0x22000 0x2000>;
clock-frequency = <48000000>;
@@ -272,7 +272,7 @@
};
uart3: uart@24000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart3";
reg = <0x24000 0x2000>;
clock-frequency = <48000000>;
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -371,7 +371,7 @@
};
uart1: uart@48020000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart1";
reg = <0x48020000 0x2000>;
clock-frequency = <48000000>;
@@ -381,7 +381,7 @@
};
uart2: uart@48022000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart2";
reg = <0x48022000 0x2000>;
clock-frequency = <48000000>;
@@ -391,7 +391,7 @@
};
uart3: uart@48024000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart3";
reg = <0x48024000 0x2000>;
clock-frequency = <48000000>;
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix am335x and dm814x scm syscon to probe children
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 11:10:40 -0800
Subject: ARM: dts: Fix am335x and dm814x scm syscon to probe children
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit 1aa09df0854efe16b7a80358a18f0a0bebafd246 ]
Without these changes children of the scn syscon
won't probe.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/am33xx.dtsi | 3 ++-
arch/arm/boot/dts/dm814x.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -143,10 +143,11 @@
};
scm_conf: scm_conf@0 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0 0x800>;
scm_clocks: clocks {
#address-cells = <1>;
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -332,10 +332,11 @@
ranges = <0 0x140000 0x20000>;
scm_conf: scm_conf@0 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0 0x800>;
scm_clocks: clocks {
#address-cells = <1>;
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.9/arm-dts-omap5-uevm-allow-bootloader-to-configure-usb-ethernet-mac.patch
queue-4.9/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.9/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.9/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.9/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
ALSA: vx: Don't try to update capture stream before running
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-vx-don-t-try-to-update-capture-stream-before-running.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 4 Jan 2017 12:34:14 +0100
Subject: ALSA: vx: Don't try to update capture stream before running
From: Takashi Iwai <tiwai(a)suse.de>
[ Upstream commit ed3c177d960bb5881b945ca6f784868126bb90db ]
The update of stream costs significantly, and we should avoid it
unless the stream really has started. Check pipe->running flag
instead of pipe->prepared.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/vx/vx_pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/drivers/vx/vx_pcm.c
+++ b/sound/drivers/vx/vx_pcm.c
@@ -1015,7 +1015,7 @@ static void vx_pcm_capture_update(struct
int size, space, count;
struct snd_pcm_runtime *runtime = subs->runtime;
- if (! pipe->prepared || (chip->chip_status & VX_STAT_IS_STALE))
+ if (!pipe->running || (chip->chip_status & VX_STAT_IS_STALE))
return;
size = runtime->buffer_size - snd_pcm_capture_avail(runtime);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-vx-don-t-try-to-update-capture-stream-before-running.patch
queue-4.9/alsa-vx-fix-possible-transfer-overflow.patch
queue-4.9/alsa-hda-realtek-add-new-codec-id-alc299.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda/realtek - Add new codec ID ALC299
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-hda-realtek-add-new-codec-id-alc299.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:32:28 CET 2017
From: Kailang Yang <kailang(a)realtek.com>
Date: Wed, 4 Jan 2017 14:49:07 +0800
Subject: ALSA: hda/realtek - Add new codec ID ALC299
From: Kailang Yang <kailang(a)realtek.com>
[ Upstream commit 28f1f9b26cee161ddd3985b3eb78e3ffada08dda ]
ALC299 was similar as ALC225.
Add headset support for ALC299.
ALC3271 was for Dell rename.
Signed-off-by: Kailang Yang <kailang(a)realtek.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -338,6 +338,7 @@ static void alc_fill_eapd_coef(struct hd
case 0x10ec0288:
case 0x10ec0295:
case 0x10ec0298:
+ case 0x10ec0299:
alc_update_coef_idx(codec, 0x10, 1<<9, 0);
break;
case 0x10ec0285:
@@ -914,6 +915,7 @@ static struct alc_codec_rename_pci_table
{ 0x10ec0256, 0x1028, 0, "ALC3246" },
{ 0x10ec0225, 0x1028, 0, "ALC3253" },
{ 0x10ec0295, 0x1028, 0, "ALC3254" },
+ { 0x10ec0299, 0x1028, 0, "ALC3271" },
{ 0x10ec0670, 0x1025, 0, "ALC669X" },
{ 0x10ec0676, 0x1025, 0, "ALC679X" },
{ 0x10ec0282, 0x1043, 0, "ALC3229" },
@@ -3721,6 +3723,7 @@ static void alc_headset_mode_unplugged(s
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
break;
case 0x10ec0867:
@@ -3829,6 +3832,7 @@ static void alc_headset_mode_mic_in(stru
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_update_coef_idx(codec, 0x45, 0x3f<<10, 0x31<<10);
snd_hda_set_pin_ctl_cache(codec, hp_pin, 0);
alc_process_coef_fw(codec, coef0225);
@@ -3887,6 +3891,7 @@ static void alc_headset_mode_default(str
switch (codec->core.vendor_id) {
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
break;
case 0x10ec0236:
@@ -4004,6 +4009,7 @@ static void alc_headset_mode_ctia(struct
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
break;
case 0x10ec0867:
@@ -4098,6 +4104,7 @@ static void alc_headset_mode_omtp(struct
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
break;
}
@@ -4183,6 +4190,7 @@ static void alc_determine_headset_type(s
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
msleep(800);
val = alc_read_coef_idx(codec, 0x46);
@@ -6251,6 +6259,7 @@ static int patch_alc269(struct hda_codec
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
spec->codec_variant = ALC269_TYPE_ALC225;
break;
case 0x10ec0234:
@@ -7249,6 +7258,7 @@ static const struct hda_device_id snd_hd
HDA_CODEC_ENTRY(0x10ec0294, "ALC294", patch_alc269),
HDA_CODEC_ENTRY(0x10ec0295, "ALC295", patch_alc269),
HDA_CODEC_ENTRY(0x10ec0298, "ALC298", patch_alc269),
+ HDA_CODEC_ENTRY(0x10ec0299, "ALC299", patch_alc269),
HDA_CODEC_REV_ENTRY(0x10ec0861, 0x100340, "ALC660", patch_alc861),
HDA_CODEC_ENTRY(0x10ec0660, "ALC660-VD", patch_alc861vd),
HDA_CODEC_ENTRY(0x10ec0861, "ALC861", patch_alc861),
Patches currently in stable-queue which might be from kailang(a)realtek.com are
queue-4.9/alsa-hda-realtek-add-new-codec-id-alc299.patch
From: Adam Wallis <awallis(a)codeaurora.org>
commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream.
This patch was backported and only needed a line adjustment.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks). Ideally, this would be
cleaned up in the thread handler, but at the very least, the kernel
is left in a very precarious scenario that can lead to some long debug
sessions when the crash comes later.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
---
drivers/dma/dmatest.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index b8576fd..1c7568c 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -634,6 +634,7 @@ static int dmatest_func(void *data)
* free it this time?" dancing. For now, just
* leave it dangling.
*/
+ WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Here are two target patches for v3.18.y stable, the first of which
did not originally include a stable CC, and the latter did not apply
due to a minor context change.
The series has been cut against v3.18.81. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Nicholas Bellinger (1):
iscsi-target: Fix iscsi_np reset hung task during parallel delete
drivers/target/iscsi/iscsi_target.c | 20 ++++++++------------
drivers/target/iscsi/iscsi_target_core.h | 1 +
drivers/target/iscsi/iscsi_target_login.c | 7 +++++--
include/target/iscsi/iscsi_target_core.h | 1 +
include/target/target_core_base.h | 1 +
5 files changed, 16 insertions(+), 14 deletions(-)
--
1.8.5.3
Hi,
Please include commit ("abde15d5eb3d Bluetooth: btusb: fix QCA Rome suspend/resume”) to stable.
QCA ROME support was introduced in v4.1, so it should be included in v4.4+.
This issue can solve a BLE connection issue for QCA ROME devices.
Kai-Heng
This is a note to let you know that I've just added the patch titled
xen-blkback: don't leak stack data via response ring
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xen-blkback-don-t-leak-stack-data-via-response-ring.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Jan Beulich <jbeulich(a)suse.com>
Date: Tue, 13 Jun 2017 16:28:27 -0400
Subject: xen-blkback: don't leak stack data via response ring
From: Jan Beulich <jbeulich(a)suse.com>
commit 089bc0143f489bd3a4578bdff5f4ca68fb26f341 upstream.
Rather than constructing a local structure instance on the stack, fill
the fields directly on the shared ring, just like other backends do.
Build on the fact that all response structure flavors are actually
identical (the old code did make this assumption too).
This is XSA-216.
Signed-off-by: Jan Beulich <jbeulich(a)suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
[bwh: Backported to 4.4: adjust context]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/xen-blkback/blkback.c | 23 ++++++++++++-----------
drivers/block/xen-blkback/common.h | 25 +++++--------------------
2 files changed, 17 insertions(+), 31 deletions(-)
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -1407,33 +1407,34 @@ static int dispatch_rw_block_io(struct x
static void make_response(struct xen_blkif *blkif, u64 id,
unsigned short op, int st)
{
- struct blkif_response resp;
+ struct blkif_response *resp;
unsigned long flags;
union blkif_back_rings *blk_rings = &blkif->blk_rings;
int notify;
- resp.id = id;
- resp.operation = op;
- resp.status = st;
-
spin_lock_irqsave(&blkif->blk_ring_lock, flags);
/* Place on the response ring for the relevant domain. */
switch (blkif->blk_protocol) {
case BLKIF_PROTOCOL_NATIVE:
- memcpy(RING_GET_RESPONSE(&blk_rings->native, blk_rings->native.rsp_prod_pvt),
- &resp, sizeof(resp));
+ resp = RING_GET_RESPONSE(&blk_rings->native,
+ blk_rings->native.rsp_prod_pvt);
break;
case BLKIF_PROTOCOL_X86_32:
- memcpy(RING_GET_RESPONSE(&blk_rings->x86_32, blk_rings->x86_32.rsp_prod_pvt),
- &resp, sizeof(resp));
+ resp = RING_GET_RESPONSE(&blk_rings->x86_32,
+ blk_rings->x86_32.rsp_prod_pvt);
break;
case BLKIF_PROTOCOL_X86_64:
- memcpy(RING_GET_RESPONSE(&blk_rings->x86_64, blk_rings->x86_64.rsp_prod_pvt),
- &resp, sizeof(resp));
+ resp = RING_GET_RESPONSE(&blk_rings->x86_64,
+ blk_rings->x86_64.rsp_prod_pvt);
break;
default:
BUG();
}
+
+ resp->id = id;
+ resp->operation = op;
+ resp->status = st;
+
blk_rings->common.rsp_prod_pvt++;
RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&blk_rings->common, notify);
spin_unlock_irqrestore(&blkif->blk_ring_lock, flags);
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -74,9 +74,8 @@ extern unsigned int xen_blkif_max_ring_o
struct blkif_common_request {
char dummy;
};
-struct blkif_common_response {
- char dummy;
-};
+
+/* i386 protocol version */
struct blkif_x86_32_request_rw {
uint8_t nr_segments; /* number of segments */
@@ -128,14 +127,6 @@ struct blkif_x86_32_request {
} u;
} __attribute__((__packed__));
-/* i386 protocol version */
-#pragma pack(push, 4)
-struct blkif_x86_32_response {
- uint64_t id; /* copied from request */
- uint8_t operation; /* copied from request */
- int16_t status; /* BLKIF_RSP_??? */
-};
-#pragma pack(pop)
/* x86_64 protocol version */
struct blkif_x86_64_request_rw {
@@ -192,18 +183,12 @@ struct blkif_x86_64_request {
} u;
} __attribute__((__packed__));
-struct blkif_x86_64_response {
- uint64_t __attribute__((__aligned__(8))) id;
- uint8_t operation; /* copied from request */
- int16_t status; /* BLKIF_RSP_??? */
-};
-
DEFINE_RING_TYPES(blkif_common, struct blkif_common_request,
- struct blkif_common_response);
+ struct blkif_response);
DEFINE_RING_TYPES(blkif_x86_32, struct blkif_x86_32_request,
- struct blkif_x86_32_response);
+ struct blkif_response __packed);
DEFINE_RING_TYPES(blkif_x86_64, struct blkif_x86_64_request,
- struct blkif_x86_64_response);
+ struct blkif_response);
union blkif_back_rings {
struct blkif_back_ring native;
Patches currently in stable-queue which might be from jbeulich(a)suse.com are
queue-4.4/xen-blkback-don-t-leak-stack-data-via-response-ring.patch
This is a note to let you know that I've just added the patch titled
sctp: do not peel off an assoc from one netns to another one
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-do-not-peel-off-an-assoc-from-one-netns-to-another-one.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Tue, 17 Oct 2017 23:26:10 +0800
Subject: sctp: do not peel off an assoc from one netns to another one
From: Xin Long <lucien.xin(a)gmail.com>
commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 upstream.
Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.
As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.
This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:
socket$inet6_sctp()
bind$inet6()
sendto$inet6()
unshare(0x40000000)
getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.
Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually
different.
Reported-by: ChunYu Wang <chunwang(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4453,6 +4453,10 @@ int sctp_do_peeloff(struct sock *sk, sct
struct socket *sock;
int err = 0;
+ /* Do not peel off from one netns to another one. */
+ if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
+ return -EINVAL;
+
if (!asoc)
return -EINVAL;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.4/sctp-do-not-peel-off-an-assoc-from-one-netns-to-another-one.patch
This is a note to let you know that I've just added the patch titled
net: cdc_ether: fix divide by 0 on bad descriptors
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-cdc_ether-fix-divide-by-0-on-bad-descriptors.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Bjørn Mork <bjorn(a)mork.no>
Date: Mon, 6 Nov 2017 15:37:22 +0100
Subject: net: cdc_ether: fix divide by 0 on bad descriptors
From: Bjørn Mork <bjorn(a)mork.no>
commit 2cb80187ba065d7decad7c6614e35e07aec8a974 upstream.
Setting dev->hard_mtu to 0 will cause a divide error in
usbnet_probe. Protect against devices with bogus CDC Ethernet
functional descriptors by ignoring a zero wMaxSegmentSize.
Signed-off-by: Bjørn Mork <bjorn(a)mork.no>
Acked-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/cdc_ether.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -221,7 +221,7 @@ skip:
goto bad_desc;
}
- if (header.usb_cdc_ether_desc) {
+ if (header.usb_cdc_ether_desc && info->ether->wMaxSegmentSize) {
dev->hard_mtu = le16_to_cpu(info->ether->wMaxSegmentSize);
/* because of Zaurus, we may be ignoring the host
* side link address we were given.
Patches currently in stable-queue which might be from bjorn(a)mork.no are
queue-4.4/net-cdc_ether-fix-divide-by-0-on-bad-descriptors.patch
queue-4.4/net-qmi_wwan-fix-divide-by-0-on-bad-descriptors.patch
This is a note to let you know that I've just added the patch titled
net: qmi_wwan: fix divide by 0 on bad descriptors
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-qmi_wwan-fix-divide-by-0-on-bad-descriptors.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Bjørn Mork <bjorn(a)mork.no>
Date: Mon, 6 Nov 2017 15:32:18 +0100
Subject: net: qmi_wwan: fix divide by 0 on bad descriptors
From: Bjørn Mork <bjorn(a)mork.no>
commit 7fd078337201cf7468f53c3d9ef81ff78cb6df3b upstream.
A CDC Ethernet functional descriptor with wMaxSegmentSize = 0 will
cause a divide error in usbnet_probe:
divide error: 0000 [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006bef5c00 task.stack: ffff88006bf60000
RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
RSP: 0018:ffff88006bf67508 EFLAGS: 00010246
RAX: 00000000000163c8 RBX: ffff8800621fce40 RCX: ffff8800621fcf34
RDX: 0000000000000000 RSI: ffffffff837ecb7a RDI: ffff8800621fcf34
RBP: ffff88006bf67520 R08: ffff88006bef5c00 R09: ffffed000c43f881
R10: ffffed000c43f880 R11: ffff8800621fc406 R12: 0000000000000003
R13: ffffffff85c71de0 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe9c0d6dac CR3: 00000000614f4000 CR4: 00000000000006f0
Call Trace:
usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338
usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x522/0x740 drivers/base/dd.c:557
Fix by simply ignoring the bogus descriptor, as it is optional
for QMI devices anyway.
Fixes: 423ce8caab7e ("net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices")
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Bjørn Mork <bjorn(a)mork.no>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -262,7 +262,7 @@ static int qmi_wwan_bind(struct usbnet *
}
/* errors aren't fatal - we can live with the dynamic address */
- if (cdc_ether) {
+ if (cdc_ether && cdc_ether->wMaxSegmentSize) {
dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize);
usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
}
Patches currently in stable-queue which might be from bjorn(a)mork.no are
queue-4.4/net-cdc_ether-fix-divide-by-0-on-bad-descriptors.patch
queue-4.4/net-qmi_wwan-fix-divide-by-0-on-bad-descriptors.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2419,6 +2419,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.4/media-imon-fix-null-ptr-deref-in-imon_probe.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: fix singlestepping over syscall
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-x86-fix-singlestepping-over-syscall.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Wed, 7 Jun 2017 15:13:14 +0200
Subject: KVM: x86: fix singlestepping over syscall
From: Paolo Bonzini <pbonzini(a)redhat.com>
commit c8401dda2f0a00cd25c0af6a95ed50e478d25de4 upstream.
TF is handled a bit differently for syscall and sysret, compared
to the other instructions: TF is checked after the instruction completes,
so that the OS can disable #DB at a syscall by adding TF to FMASK.
When the sysret is executed the #DB is taken "as if" the syscall insn
just completed.
KVM emulates syscall so that it can trap 32-bit syscall on Intel processors.
Fix the behavior, otherwise you could get #DB on a user stack which is not
nice. This does not affect Linux guests, as they use an IST or task gate
for #DB.
This fixes CVE-2017-7518.
Reported-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
[bwh: Backported to 4.4:
- kvm_vcpu_check_singlestep() sets some flags differently
- Drop changes to kvm_skip_emulated_instruction()]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/kvm_emulate.h | 1
arch/x86/kvm/emulate.c | 1
arch/x86/kvm/x86.c | 52 +++++++++++++++----------------------
3 files changed, 24 insertions(+), 30 deletions(-)
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -296,6 +296,7 @@ struct x86_emulate_ctxt {
bool perm_ok; /* do not check permissions if true */
bool ud; /* inject an #UD if host doesn't support insn */
+ bool tf; /* TF value before instruction (after for syscall/sysret) */
bool have_exception;
struct x86_exception exception;
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2726,6 +2726,7 @@ static int em_syscall(struct x86_emulate
ctxt->eflags &= ~(X86_EFLAGS_VM | X86_EFLAGS_IF);
}
+ ctxt->tf = (ctxt->eflags & X86_EFLAGS_TF) != 0;
return X86EMUL_CONTINUE;
}
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5095,6 +5095,8 @@ static void init_emulate_ctxt(struct kvm
kvm_x86_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
ctxt->eflags = kvm_get_rflags(vcpu);
+ ctxt->tf = (ctxt->eflags & X86_EFLAGS_TF) != 0;
+
ctxt->eip = kvm_rip_read(vcpu);
ctxt->mode = (!is_protmode(vcpu)) ? X86EMUL_MODE_REAL :
(ctxt->eflags & X86_EFLAGS_VM) ? X86EMUL_MODE_VM86 :
@@ -5315,37 +5317,26 @@ static int kvm_vcpu_check_hw_bp(unsigned
return dr6;
}
-static void kvm_vcpu_check_singlestep(struct kvm_vcpu *vcpu, unsigned long rflags, int *r)
+static void kvm_vcpu_do_singlestep(struct kvm_vcpu *vcpu, int *r)
{
struct kvm_run *kvm_run = vcpu->run;
- /*
- * rflags is the old, "raw" value of the flags. The new value has
- * not been saved yet.
- *
- * This is correct even for TF set by the guest, because "the
- * processor will not generate this exception after the instruction
- * that sets the TF flag".
- */
- if (unlikely(rflags & X86_EFLAGS_TF)) {
- if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
- kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 |
- DR6_RTM;
- kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip;
- kvm_run->debug.arch.exception = DB_VECTOR;
- kvm_run->exit_reason = KVM_EXIT_DEBUG;
- *r = EMULATE_USER_EXIT;
- } else {
- vcpu->arch.emulate_ctxt.eflags &= ~X86_EFLAGS_TF;
- /*
- * "Certain debug exceptions may clear bit 0-3. The
- * remaining contents of the DR6 register are never
- * cleared by the processor".
- */
- vcpu->arch.dr6 &= ~15;
- vcpu->arch.dr6 |= DR6_BS | DR6_RTM;
- kvm_queue_exception(vcpu, DB_VECTOR);
- }
+ if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
+ kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 | DR6_RTM;
+ kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip;
+ kvm_run->debug.arch.exception = DB_VECTOR;
+ kvm_run->exit_reason = KVM_EXIT_DEBUG;
+ *r = EMULATE_USER_EXIT;
+ } else {
+ vcpu->arch.emulate_ctxt.eflags &= ~X86_EFLAGS_TF;
+ /*
+ * "Certain debug exceptions may clear bit 0-3. The
+ * remaining contents of the DR6 register are never
+ * cleared by the processor".
+ */
+ vcpu->arch.dr6 &= ~15;
+ vcpu->arch.dr6 |= DR6_BS | DR6_RTM;
+ kvm_queue_exception(vcpu, DB_VECTOR);
}
}
@@ -5500,8 +5491,9 @@ restart:
toggle_interruptibility(vcpu, ctxt->interruptibility);
vcpu->arch.emulate_regs_need_sync_to_vcpu = false;
kvm_rip_write(vcpu, ctxt->eip);
- if (r == EMULATE_DONE)
- kvm_vcpu_check_singlestep(vcpu, rflags, &r);
+ if (r == EMULATE_DONE &&
+ (ctxt->tf || (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)))
+ kvm_vcpu_do_singlestep(vcpu, &r);
if (!ctxt->have_exception ||
exception_type(ctxt->exception.vector) == EXCPT_TRAP)
__kvm_set_rflags(vcpu, ctxt->eflags);
Patches currently in stable-queue which might be from pbonzini(a)redhat.com are
queue-4.4/kvm-x86-fix-singlestepping-over-syscall.patch
This is a note to let you know that I've just added the patch titled
ext4: fix data exposure after a crash
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-data-exposure-after-a-crash.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Sun, 24 Apr 2016 00:56:03 -0400
Subject: ext4: fix data exposure after a crash
From: Jan Kara <jack(a)suse.cz>
commit 06bd3c36a733ac27962fea7d6f47168841376824 upstream.
Huang has reported that in his powerfail testing he is seeing stale
block contents in some of recently allocated blocks although he mounts
ext4 in data=ordered mode. After some investigation I have found out
that indeed when delayed allocation is used, we don't add inode to
transaction's list of inodes needing flushing before commit. Originally
we were doing that but commit f3b59291a69d removed the logic with a
flawed argument that it is not needed.
The problem is that although for delayed allocated blocks we write their
contents immediately after allocating them, there is no guarantee that
the IO scheduler or device doesn't reorder things and thus transaction
allocating blocks and attaching them to inode can reach stable storage
before actual block contents. Actually whenever we attach freshly
allocated blocks to inode using a written extent, we should add inode to
transaction's ordered inode list to make sure we properly wait for block
contents to be written before committing the transaction. So that is
what we do in this patch. This also handles other cases where stale data
exposure was possible - like filling hole via mmap in
data=ordered,nodelalloc mode.
The only exception to the above rule are extending direct IO writes where
blkdev_direct_IO() waits for IO to complete before increasing i_size and
thus stale data exposure is not possible. For now we don't complicate
the code with optimizing this special case since the overhead is pretty
low. In case this is observed to be a performance problem we can always
handle it using a special flag to ext4_map_blocks().
Fixes: f3b59291a69d0b734be1fc8be489fef2dd846d3d
Reported-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang(a)cn.bosch.com>
Tested-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang(a)cn.bosch.com>
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
[bwh: Backported to 4.4:
- Drop check for EXT4_GET_BLOCKS_ZERO flag
- Adjust context]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/inode.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -658,6 +658,20 @@ has_zeroout:
ret = check_block_validity(inode, map);
if (ret != 0)
return ret;
+
+ /*
+ * Inodes with freshly allocated blocks where contents will be
+ * visible after transaction commit must be on transaction's
+ * ordered data list.
+ */
+ if (map->m_flags & EXT4_MAP_NEW &&
+ !(map->m_flags & EXT4_MAP_UNWRITTEN) &&
+ !IS_NOQUOTA(inode) &&
+ ext4_should_order_data(inode)) {
+ ret = ext4_jbd2_file_inode(handle, inode);
+ if (ret)
+ return ret;
+ }
}
return retval;
}
@@ -1152,15 +1166,6 @@ static int ext4_write_end(struct file *f
int i_size_changed = 0;
trace_ext4_write_end(inode, pos, len, copied);
- if (ext4_test_inode_state(inode, EXT4_STATE_ORDERED_MODE)) {
- ret = ext4_jbd2_file_inode(handle, inode);
- if (ret) {
- unlock_page(page);
- page_cache_release(page);
- goto errout;
- }
- }
-
if (ext4_has_inline_data(inode)) {
ret = ext4_write_inline_data_end(inode, pos, len,
copied, page);
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.4/ext4-fix-data-exposure-after-a-crash.patch
This is a note to let you know that I've just added the patch titled
bpf: don't let ldimm64 leak map addresses on unprivileged
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bpf-don-t-let-ldimm64-leak-map-addresses-on-unprivileged.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Daniel Borkmann <daniel(a)iogearbox.net>
Date: Mon, 8 May 2017 00:04:09 +0200
Subject: bpf: don't let ldimm64 leak map addresses on unprivileged
From: Daniel Borkmann <daniel(a)iogearbox.net>
commit 0d0e57697f162da4aa218b5feafe614fb666db07 upstream.
The patch fixes two things at once:
1) It checks the env->allow_ptr_leaks and only prints the map address to
the log if we have the privileges to do so, otherwise it just dumps 0
as we would when kptr_restrict is enabled on %pK. Given the latter is
off by default and not every distro sets it, I don't want to rely on
this, hence the 0 by default for unprivileged.
2) Printing of ldimm64 in the verifier log is currently broken in that
we don't print the full immediate, but only the 32 bit part of the
first insn part for ldimm64. Thus, fix this up as well; it's okay to
access, since we verified all ldimm64 earlier already (including just
constants) through replace_map_fd_with_map_ptr().
Fixes: 1be7f75d1668 ("bpf: enable non-root eBPF programs")
Fixes: cbd357008604 ("bpf: verifier (add ability to receive verification log)")
Reported-by: Jann Horn <jannh(a)google.com>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Acked-by: Alexei Starovoitov <ast(a)kernel.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
[bwh: Backported to 4.4: s/bpf_verifier_env/verifier_env/]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/bpf/verifier.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -313,7 +313,8 @@ static const char *const bpf_jmp_string[
[BPF_EXIT >> 4] = "exit",
};
-static void print_bpf_insn(struct bpf_insn *insn)
+static void print_bpf_insn(const struct verifier_env *env,
+ const struct bpf_insn *insn)
{
u8 class = BPF_CLASS(insn->code);
@@ -377,9 +378,19 @@ static void print_bpf_insn(struct bpf_in
insn->code,
bpf_ldst_string[BPF_SIZE(insn->code) >> 3],
insn->src_reg, insn->imm);
- } else if (BPF_MODE(insn->code) == BPF_IMM) {
- verbose("(%02x) r%d = 0x%x\n",
- insn->code, insn->dst_reg, insn->imm);
+ } else if (BPF_MODE(insn->code) == BPF_IMM &&
+ BPF_SIZE(insn->code) == BPF_DW) {
+ /* At this point, we already made sure that the second
+ * part of the ldimm64 insn is accessible.
+ */
+ u64 imm = ((u64)(insn + 1)->imm << 32) | (u32)insn->imm;
+ bool map_ptr = insn->src_reg == BPF_PSEUDO_MAP_FD;
+
+ if (map_ptr && !env->allow_ptr_leaks)
+ imm = 0;
+
+ verbose("(%02x) r%d = 0x%llx\n", insn->code,
+ insn->dst_reg, (unsigned long long)imm);
} else {
verbose("BUG_ld_%02x\n", insn->code);
return;
@@ -1764,7 +1775,7 @@ static int do_check(struct verifier_env
if (log_level) {
verbose("%d: ", insn_idx);
- print_bpf_insn(insn);
+ print_bpf_insn(env, insn);
}
if (class == BPF_ALU || class == BPF_ALU64) {
Patches currently in stable-queue which might be from daniel(a)iogearbox.net are
queue-4.4/bpf-don-t-let-ldimm64-leak-map-addresses-on-unprivileged.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 4.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-4.13 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2516,6 +2516,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.13/media-imon-fix-null-ptr-deref-in-imon_probe.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2412,6 +2412,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.9/media-imon-fix-null-ptr-deref-in-imon_probe.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2419,6 +2419,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-3.18/media-imon-fix-null-ptr-deref-in-imon_probe.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2517,6 +2517,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.14/media-imon-fix-null-ptr-deref-in-imon_probe.patch
These fixes are needed in stable branches, but don't have a Cc: stable
or Fixes: tag:
58fd55e83827 media: imon: Fix null-ptr-deref in imon_probe
eb0c19942288 media: dib0700: fix invalid dvb_detach argument
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
From: Josef Bacik <jbacik(a)fb.com>
We discovered a box that had double allocations, and suspected the space
cache may be to blame. While auditing the write out path I noticed that
if we've already setup the space cache we will just carry on. This
means that any error we hit after cache_save_setup before we go to
actually write the cache out we won't reset the inode generation, so
whatever was already written will be considered correct, except it'll be
stale. Fix this by _always_ resetting the generation on the block group
inode, this way we only ever have valid or invalid cache.
With this patch I was no longer able to reproduce cache corruption with
dm-log-writes and my bpf error injection tool.
Cc: stable(a)vger.kernel.org
Signed-off-by: Josef Bacik <jbacik(a)fb.com>
---
fs/btrfs/extent-tree.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index e2d7e86b51d1..67b26b209e23 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3526,13 +3526,6 @@ static int cache_save_setup(struct btrfs_block_group_cache *block_group,
goto again;
}
- /* We've already setup this transaction, go ahead and exit */
- if (block_group->cache_generation == trans->transid &&
- i_size_read(inode)) {
- dcs = BTRFS_DC_SETUP;
- goto out_put;
- }
-
/*
* We want to set the generation to 0, that way if anything goes wrong
* from here on out we know not to trust this cache when we load up next
@@ -3556,6 +3549,13 @@ static int cache_save_setup(struct btrfs_block_group_cache *block_group,
}
WARN_ON(ret);
+ /* We've already setup this transaction, go ahead and exit */
+ if (block_group->cache_generation == trans->transid &&
+ i_size_read(inode)) {
+ dcs = BTRFS_DC_SETUP;
+ goto out_put;
+ }
+
if (i_size_read(inode) > 0) {
ret = btrfs_check_trunc_cache_free_space(fs_info,
&fs_info->global_block_rsv);
--
2.7.5
From: Bob Moore <robert.moore(a)intel.com>
[ Upstream commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3 ]
ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1
ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a
ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e
The declared buffer length must be the same as the length of the
byte initializer list, otherwise not a valid resource descriptor.
Link: https://github.com/acpica/acpica/commit/9f76de2d
Link: https://github.com/acpica/acpica/commit/b2e89d72
Link: https://github.com/acpica/acpica/commit/23b5bbe6
Signed-off-by: Bob Moore <robert.moore(a)intel.com>
Signed-off-by: Lv Zheng <lv.zheng(a)intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
---
drivers/acpi/acpica/utresrc.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/utresrc.c b/drivers/acpi/acpica/utresrc.c
index 1de3376da66a..2ad99ea3d496 100644
--- a/drivers/acpi/acpica/utresrc.c
+++ b/drivers/acpi/acpica/utresrc.c
@@ -421,8 +421,10 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
ACPI_FUNCTION_TRACE(ut_walk_aml_resources);
- /* The absolute minimum resource template is one end_tag descriptor */
-
+ /*
+ * The absolute minimum resource template is one end_tag descriptor.
+ * However, we will treat a lone end_tag as just a simple buffer.
+ */
if (aml_length < sizeof(struct aml_resource_end_tag)) {
return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG);
}
@@ -454,9 +456,8 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
/* Invoke the user function */
if (user_function) {
- status =
- user_function(aml, length, offset, resource_index,
- context);
+ status = user_function(aml, length, offset,
+ resource_index, context);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
@@ -480,6 +481,12 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
*context = aml;
}
+ /* Check if buffer is defined to be longer than the resource length */
+
+ if (aml_length > (offset + length)) {
+ return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG);
+ }
+
/* Normal exit */
return_ACPI_STATUS(AE_OK);
--
2.11.0
From: Andreas Rohner <andreas.rohner(a)gmx.net>
Subject: nilfs2: fix race condition that causes file system corruption
There is a race condition between nilfs_dirty_inode() and
nilfs_set_file_dirty().
When a file is opened, nilfs_dirty_inode() is called to update the access
timestamp in the inode. It calls __nilfs_mark_inode_dirty() in a separate
transaction. __nilfs_mark_inode_dirty() caches the ifile buffer_head in
the i_bh field of the inode info structure and marks it as dirty.
After some data was written to the file in another transaction, the
function nilfs_set_file_dirty() is called, which adds the inode to the
ns_dirty_files list.
Then the segment construction calls nilfs_segctor_collect_dirty_files(),
which goes through the ns_dirty_files list and checks the i_bh field. If
there is a cached buffer_head in i_bh it is not marked as dirty again.
Since nilfs_dirty_inode() and nilfs_set_file_dirty() use separate
transactions, it is possible that a segment construction that writes out
the ifile occurs in-between the two. If this happens the inode is not on
the ns_dirty_files list, but its ifile block is still marked as dirty and
written out.
In the next segment construction, the data for the file is written out and
nilfs_bmap_propagate() updates the b-tree. Eventually the bmap root is
written into the i_bh block, which is not dirty, because it was written
out in another segment construction.
As a result the bmap update can be lost, which leads to file system
corruption. Either the virtual block address points to an unallocated DAT
block, or the DAT entry will be reused for something different.
The error can remain undetected for a long time. A typical error message
would be one of the "bad btree" errors or a warning that a DAT entry could
not be found.
This bug can be reproduced reliably by a simple benchmark that creates and
overwrites millions of 4k files.
Link: http://lkml.kernel.org/r/1509367935-3086-2-git-send-email-konishi.ryusuke@l…
Signed-off-by: Andreas Rohner <andreas.rohner(a)gmx.net>
Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)lab.ntt.co.jp>
Tested-by: Andreas Rohner <andreas.rohner(a)gmx.net>
Tested-by: Ryusuke Konishi <konishi.ryusuke(a)lab.ntt.co.jp>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/nilfs2/segment.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff -puN fs/nilfs2/segment.c~nilfs2-fix-race-condition-that-causes-file-system-corruption fs/nilfs2/segment.c
--- a/fs/nilfs2/segment.c~nilfs2-fix-race-condition-that-causes-file-system-corruption
+++ a/fs/nilfs2/segment.c
@@ -1954,8 +1954,6 @@ static int nilfs_segctor_collect_dirty_f
err, ii->vfs_inode.i_ino);
return err;
}
- mark_buffer_dirty(ibh);
- nilfs_mdt_mark_dirty(ifile);
spin_lock(&nilfs->ns_inode_lock);
if (likely(!ii->i_bh))
ii->i_bh = ibh;
@@ -1964,6 +1962,10 @@ static int nilfs_segctor_collect_dirty_f
goto retry;
}
+ // Always redirty the buffer to avoid race condition
+ mark_buffer_dirty(ii->i_bh);
+ nilfs_mdt_mark_dirty(ifile);
+
clear_bit(NILFS_I_QUEUED, &ii->i_state);
set_bit(NILFS_I_BUSY, &ii->i_state);
list_move_tail(&ii->i_dirty, &sci->sc_dirty_files);
_
From: NeilBrown <neilb(a)suse.com>
Subject: autofs: don't fail mount for transient error
Currently if the autofs kernel module gets an error when writing to the
pipe which links to the daemon, then it marks the whole moutpoint as
catatonic, and it will stop working.
It is possible that the error is transient. This can happen if the daemon
is slow and more than 16 requests queue up. If a subsequent process tries
to queue a request, and is then signalled, the write to the pipe will
return -ERESTARTSYS and autofs will take that as total failure.
So change the code to assess -ERESTARTSYS and -ENOMEM as transient
failures which only abort the current request, not the whole mountpoint.
It isn't a crash or a data corruption, but having autofs mountpoints
suddenly stop working is rather inconvenient.
Ian said:
: And given the problems with a half dozen (or so) user space applications
: consuming large amounts of CPU under heavy mount and umount activity this
: could happen more easily than we expect.
Link: http://lkml.kernel.org/r/87y3norvgp.fsf@notabene.neil.brown.name
Signed-off-by: NeilBrown <neilb(a)suse.com>
Acked-by: Ian Kent <raven(a)themaw.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/autofs4/waitq.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff -puN fs/autofs4/waitq.c~autofs-dont-fail-mount-for-transient-error fs/autofs4/waitq.c
--- a/fs/autofs4/waitq.c~autofs-dont-fail-mount-for-transient-error
+++ a/fs/autofs4/waitq.c
@@ -81,7 +81,8 @@ static int autofs4_write(struct autofs_s
spin_unlock_irqrestore(¤t->sighand->siglock, flags);
}
- return (bytes > 0);
+ /* if 'wr' returned 0 (impossible) we assume -EIO (safe) */
+ return bytes == 0 ? 0 : wr < 0 ? wr : -EIO;
}
static void autofs4_notify_daemon(struct autofs_sb_info *sbi,
@@ -95,6 +96,7 @@ static void autofs4_notify_daemon(struct
} pkt;
struct file *pipe = NULL;
size_t pktsz;
+ int ret;
pr_debug("wait id = 0x%08lx, name = %.*s, type=%d\n",
(unsigned long) wq->wait_queue_token,
@@ -169,7 +171,18 @@ static void autofs4_notify_daemon(struct
mutex_unlock(&sbi->wq_mutex);
if (autofs4_write(sbi, pipe, &pkt, pktsz))
+ switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) {
+ case 0:
+ break;
+ case -ENOMEM:
+ case -ERESTARTSYS:
+ /* Just fail this one */
+ autofs4_wait_release(sbi, wq->wait_queue_token, ret);
+ break;
+ default:
autofs4_catatonic_mode(sbi);
+ break;
+ }
fput(pipe);
}
_
From: Vitaly Wool <vitalywool(a)gmail.com>
Subject: mm/z3fold.c: use kref to prevent page free/compact race
There is a race in the current z3fold implementation between do_compact()
called in a work queue context and the page release procedure when page's
kref goes to 0. do_compact() may be waiting for page lock, which is
released by release_z3fold_page_locked right before putting the page onto
the "stale" list, and then the page may be freed as do_compact() modifies
its contents.
The mechanism currently implemented to handle that (checking the
PAGE_STALE flag) is not reliable enough. Instead, we'll use page's kref
counter to guarantee that the page is not released if its compaction is
scheduled. It then becomes compaction function's responsibility to
decrease the counter and quit immediately if the page was actually freed.
Link: http://lkml.kernel.org/r/20171117092032.00ea56f42affbed19f4fcc6c@gmail.com
Signed-off-by: Vitaly Wool <vitaly.wool(a)sonymobile.com>
Cc: <Oleksiy.Avramchenko(a)sony.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/z3fold.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff -puN mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race mm/z3fold.c
--- a/mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race
+++ a/mm/z3fold.c
@@ -404,8 +404,7 @@ static void do_compact_page(struct z3fol
WARN_ON(z3fold_page_trylock(zhdr));
else
z3fold_page_lock(zhdr);
- if (test_bit(PAGE_STALE, &page->private) ||
- !test_and_clear_bit(NEEDS_COMPACTING, &page->private)) {
+ if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) {
z3fold_page_unlock(zhdr);
return;
}
@@ -413,6 +412,11 @@ static void do_compact_page(struct z3fol
list_del_init(&zhdr->buddy);
spin_unlock(&pool->lock);
+ if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) {
+ atomic64_dec(&pool->pages_nr);
+ return;
+ }
+
z3fold_compact_page(zhdr);
unbuddied = get_cpu_ptr(pool->unbuddied);
fchunks = num_free_chunks(zhdr);
@@ -753,9 +757,11 @@ static void z3fold_free(struct z3fold_po
list_del_init(&zhdr->buddy);
spin_unlock(&pool->lock);
zhdr->cpu = -1;
+ kref_get(&zhdr->refcount);
do_compact_page(zhdr, true);
return;
}
+ kref_get(&zhdr->refcount);
queue_work_on(zhdr->cpu, pool->compact_wq, &zhdr->work);
z3fold_page_unlock(zhdr);
}
_
The patch titled
Subject: mm/z3fold.c: use kref to prevent page free/compact race
has been added to the -mm tree. Its filename is
z3fold-use-kref-to-prevent-page-free-compact-race.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/z3fold-use-kref-to-prevent-page-fr…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/z3fold-use-kref-to-prevent-page-fr…
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/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Vitaly Wool <vitalywool(a)gmail.com>
Subject: mm/z3fold.c: use kref to prevent page free/compact race
There is a race in the current z3fold implementation between do_compact()
called in a work queue context and the page release procedure when page's
kref goes to 0. do_compact() may be waiting for page lock, which is
released by release_z3fold_page_locked right before putting the page onto
the "stale" list, and then the page may be freed as do_compact() modifies
its contents.
The mechanism currently implemented to handle that (checking the
PAGE_STALE flag) is not reliable enough. Instead, we'll use page's kref
counter to guarantee that the page is not released if its compaction is
scheduled. It then becomes compaction function's responsibility to
decrease the counter and quit immediately if the page was actually freed.
Link: http://lkml.kernel.org/r/20171117092032.00ea56f42affbed19f4fcc6c@gmail.com
Signed-off-by: Vitaly Wool <vitaly.wool(a)sonymobile.com>
Cc: <Oleksiy.Avramchenko(a)sony.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/z3fold.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff -puN mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race mm/z3fold.c
--- a/mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race
+++ a/mm/z3fold.c
@@ -404,8 +404,7 @@ static void do_compact_page(struct z3fol
WARN_ON(z3fold_page_trylock(zhdr));
else
z3fold_page_lock(zhdr);
- if (test_bit(PAGE_STALE, &page->private) ||
- !test_and_clear_bit(NEEDS_COMPACTING, &page->private)) {
+ if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) {
z3fold_page_unlock(zhdr);
return;
}
@@ -413,6 +412,11 @@ static void do_compact_page(struct z3fol
list_del_init(&zhdr->buddy);
spin_unlock(&pool->lock);
+ if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) {
+ atomic64_dec(&pool->pages_nr);
+ return;
+ }
+
z3fold_compact_page(zhdr);
unbuddied = get_cpu_ptr(pool->unbuddied);
fchunks = num_free_chunks(zhdr);
@@ -753,9 +757,11 @@ static void z3fold_free(struct z3fold_po
list_del_init(&zhdr->buddy);
spin_unlock(&pool->lock);
zhdr->cpu = -1;
+ kref_get(&zhdr->refcount);
do_compact_page(zhdr, true);
return;
}
+ kref_get(&zhdr->refcount);
queue_work_on(zhdr->cpu, pool->compact_wq, &zhdr->work);
z3fold_page_unlock(zhdr);
}
_
Patches currently in -mm which might be from vitalywool(a)gmail.com are
z3fold-use-kref-to-prevent-page-free-compact-race.patch
A new field was introduced in 74d46992e0d9dee7f1f376de0d56d31614c8a17a,
bi_partno, instead of using bdev->bd_contains and encoding the partition
information in the bi_bdev field. __bio_clone_fast was changed to copy
the disk information, but not the partition information. At minimum,
this regressed bcache and caused data corruption.
Signed-off-by: Michael Lyle <mlyle(a)lyle.org>
Fixes: 74d46992e0d9dee7f1f376de0d56d31614c8a17a
Reported-by: Pavel Goran <via-bcache(a)pvgoran.name>
Reported-by: Campbell Steven <casteven(a)gmail.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Jens Axboe <axboe(a)kernel.dk>
Cc: <stable(a)vger.kernel.org>
---
block/bio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/bio.c b/block/bio.c
index 101c2a9b5481..33fa6b4af312 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -597,6 +597,7 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src)
* so we don't set nor calculate new physical/hw segment counts here
*/
bio->bi_disk = bio_src->bi_disk;
+ bio->bi_partno = bio_src->bi_partno;
bio_set_flag(bio, BIO_CLONED);
bio->bi_opf = bio_src->bi_opf;
bio->bi_write_hint = bio_src->bi_write_hint;
--
2.14.1
Resending as the first attempt is not showing up in the list archive.
This patch converts several network drivers to use smp_rmb
rather than read_barrier_depends. The initial issue was
discovered with ixgbe on a Power machine which resulted
in skb list corruption due to fetching a stale skb pointer.
More details can be found in the ixgbe patch description.
Brian King (7):
ixgbe: Fix skb list corruption on Power systems
i40e: Use smp_rmb rather than read_barrier_depends
ixgbevf: Use smp_rmb rather than read_barrier_depends
igbvf: Use smp_rmb rather than read_barrier_depends
igb: Use smp_rmb rather than read_barrier_depends
fm10k: Use smp_rmb rather than read_barrier_depends
i40evf: Use smp_rmb rather than read_barrier_depends
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +-
8 files changed, 9 insertions(+), 8 deletions(-)
--
1.8.3.1
This is the start of the stable review cycle for the 4.9.63 release.
There are 39 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat Nov 18 17:42:01 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.63-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.63-rc1
Willy Tarreau <w(a)1wt.eu>
misc: panel: properly restore atomic counter on error path
Nicholas Bellinger <nab(a)linux-iscsi.org>
qla2xxx: Fix incorrect tcm_qla2xxx_free_cmd use during TMR ABORT (v2)
Bart Van Assche <bart.vanassche(a)sandisk.com>
target/iscsi: Fix iSCSI task reassignment handling
Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
brcmfmac: remove setting IBSS mode when stopping AP
Bilal Amarni <bilal.amarni(a)gmail.com>
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
Florian Westphal <fw(a)strlen.de>
netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"
Florian Westphal <fw(a)strlen.de>
netfilter: nat: avoid use of nf_conn_nat extension
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Cancel pending autoload work at unbinding device
Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Input: ims-psu - check if CDC union descriptor is sane
Alan Stern <stern(a)rowland.harvard.edu>
usb: usbtest: fix NULL pointer dereference
Johannes Berg <johannes.berg(a)intel.com>
mac80211: don't compare TKIP TX MIC key in reinstall prevention
Jason A. Donenfeld <Jason(a)zx2c4.com>
mac80211: use constant time comparison with keys
Johannes Berg <johannes.berg(a)intel.com>
mac80211: accept key reinstall without changing anything
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: fix race in ppp device destruction
Cong Wang <xiyou.wangcong(a)gmail.com>
net_sched: avoid matching qdisc with zero handle
Xin Long <lucien.xin(a)gmail.com>
sctp: reset owner sk for data chunks on out queues when migrating a sock
Julien Gomes <julien(a)arista.com>
tun: allow positive return values on dev_get_valid_name() call
Xin Long <lucien.xin(a)gmail.com>
ip6_gre: update dst pmtu if dev mtu has been updated by toobig in __gre6_xmit
Xin Long <lucien.xin(a)gmail.com>
ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
Xin Long <lucien.xin(a)gmail.com>
ipip: only increase err_count for some certain type icmp in ipip_err
Girish Moodalbail <girish.moodalbail(a)oracle.com>
tap: double-free in error path in tap_open()
Andrei Vagin <avagin(a)openvz.org>
net/unix: don't show information about sockets from other namespaces
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix other lockdep splats accessing ireq_opt
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix lockdep splat in inet_csk_route_req()
Laszlo Toth <laszlth(a)gmail.com>
sctp: full support for ipv6 ip_nonlocal_bind & IP_FREEBIND
Eric Dumazet <edumazet(a)google.com>
ipv6: flowlabel: do not leave opt->tot_len with garbage
Craig Gallek <kraig(a)google.com>
soreuseport: fix initialization race
Eric Dumazet <edumazet(a)google.com>
packet: avoid panic in packet_getsockopt()
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix ireq->opt races
Xin Long <lucien.xin(a)gmail.com>
sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
Cong Wang <xiyou.wangcong(a)gmail.com>
tun: call dev_get_valid_name() before register_netdevice()
Guillaume Nault <g.nault(a)alphalink.fr>
l2tp: check ps->sock before running pppol2tp_session_ioctl()
Eric Dumazet <edumazet(a)google.com>
tcp: fix tcp_mtu_probe() vs highest_sack
Eric Dumazet <edumazet(a)google.com>
net: call cgroup_sk_alloc() earlier in sk_clone_lock()
Jason A. Donenfeld <Jason(a)zx2c4.com>
netlink: do not set cb_running if dump's start() errs
Eric Dumazet <edumazet(a)google.com>
ipv6: addrconf: increment ifp refcount before ipv6_del_addr()
Craig Gallek <kraig(a)google.com>
tun/tap: sanitize TUNSETSNDBUF input
Alexey Kodanev <alexey.kodanev(a)oracle.com>
gso: fix payload length when gso_size is zero
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 +--
arch/powerpc/Kconfig | 5 -
arch/s390/Kconfig | 3 -
arch/sparc/Kconfig | 3 -
arch/x86/Kconfig | 4 -
drivers/input/misc/ims-pcu.c | 16 ++-
drivers/misc/panel.c | 23 +++-
drivers/net/macvtap.c | 20 +--
drivers/net/ppp/ppp_generic.c | 20 +++
drivers/net/tun.c | 7 +
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 3 -
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 33 -----
drivers/target/iscsi/iscsi_target.c | 19 +--
drivers/usb/misc/usbtest.c | 5 +-
include/linux/netdevice.h | 3 +
include/net/inet_sock.h | 8 +-
include/net/netfilter/nf_conntrack.h | 3 +-
include/net/netfilter/nf_nat.h | 1 -
include/net/tcp.h | 6 +-
include/target/target_core_base.h | 1 +
net/core/dev.c | 6 +-
net/core/sock.c | 3 +-
net/core/sock_reuseport.c | 12 +-
net/dccp/ipv4.c | 13 +-
net/ipv4/cipso_ipv4.c | 24 +---
net/ipv4/gre_offload.c | 2 +-
net/ipv4/inet_connection_sock.c | 9 +-
net/ipv4/inet_hashtables.c | 5 +-
net/ipv4/ipip.c | 59 ++++++---
net/ipv4/syncookies.c | 2 +-
net/ipv4/tcp_input.c | 2 +-
net/ipv4/tcp_ipv4.c | 21 +--
net/ipv4/tcp_output.c | 3 +-
net/ipv4/udp.c | 5 +-
net/ipv4/udp_offload.c | 2 +-
net/ipv6/addrconf.c | 1 +
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_gre.c | 20 ++-
net/ipv6/ip6_offload.c | 2 +-
net/ipv6/ip6_output.c | 4 +-
net/l2tp/l2tp_ppp.c | 3 +
net/mac80211/key.c | 54 +++++++-
net/netfilter/nf_conntrack_core.c | 2 +-
net/netfilter/nf_nat_core.c | 146 ++++++++-------------
net/netlink/af_netlink.c | 13 +-
net/packet/af_packet.c | 24 ++--
net/sched/sch_api.c | 2 +
net/sctp/input.c | 2 +-
net/sctp/ipv6.c | 6 +-
net/sctp/socket.c | 32 +++++
net/unix/diag.c | 2 +
security/keys/Kconfig | 4 +
sound/core/seq/seq_device.c | 3 +
54 files changed, 403 insertions(+), 293 deletions(-)
This is the start of the stable review cycle for the 4.4.99 release.
There are 28 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat Nov 18 17:41:29 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.99-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.99-rc1
Willy Tarreau <w(a)1wt.eu>
misc: panel: properly restore atomic counter on error path
Nicholas Bellinger <nab(a)linux-iscsi.org>
target: Fix node_acl demo-mode + uncached dynamic shutdown regression
Bart Van Assche <bart.vanassche(a)sandisk.com>
target/iscsi: Fix iSCSI task reassignment handling
Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
brcmfmac: remove setting IBSS mode when stopping AP
Richard Alpe <richard.alpe(a)ericsson.com>
tipc: fix link attribute propagation bug
Bilal Amarni <bilal.amarni(a)gmail.com>
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix other lockdep splats accessing ireq_opt
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix lockdep splat in inet_csk_route_req()
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix ireq->opt races
Xin Long <lucien.xin(a)gmail.com>
ipip: only increase err_count for some certain type icmp in ipip_err
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: fix race in ppp device destruction
Xin Long <lucien.xin(a)gmail.com>
sctp: reset owner sk for data chunks on out queues when migrating a sock
Julien Gomes <julien(a)arista.com>
tun: allow positive return values on dev_get_valid_name() call
Xin Long <lucien.xin(a)gmail.com>
ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
Andrei Vagin <avagin(a)openvz.org>
net/unix: don't show information about sockets from other namespaces
Eric Dumazet <edumazet(a)google.com>
ipv6: flowlabel: do not leave opt->tot_len with garbage
Eric Dumazet <edumazet(a)google.com>
packet: avoid panic in packet_getsockopt()
Xin Long <lucien.xin(a)gmail.com>
sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
Cong Wang <xiyou.wangcong(a)gmail.com>
tun: call dev_get_valid_name() before register_netdevice()
Guillaume Nault <g.nault(a)alphalink.fr>
l2tp: check ps->sock before running pppol2tp_session_ioctl()
Eric Dumazet <edumazet(a)google.com>
tcp: fix tcp_mtu_probe() vs highest_sack
Craig Gallek <kraig(a)google.com>
tun/tap: sanitize TUNSETSNDBUF input
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Cancel pending autoload work at unbinding device
Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Input: ims-psu - check if CDC union descriptor is sane
Alan Stern <stern(a)rowland.harvard.edu>
usb: usbtest: fix NULL pointer dereference
Johannes Berg <johannes.berg(a)intel.com>
mac80211: don't compare TKIP TX MIC key in reinstall prevention
Jason A. Donenfeld <Jason(a)zx2c4.com>
mac80211: use constant time comparison with keys
Johannes Berg <johannes.berg(a)intel.com>
mac80211: accept key reinstall without changing anything
-------------
Diffstat:
Makefile | 4 +-
arch/powerpc/Kconfig | 5 --
arch/s390/Kconfig | 3 --
arch/sparc/Kconfig | 3 --
arch/x86/Kconfig | 4 --
drivers/input/misc/ims-pcu.c | 16 +++++-
drivers/net/macvtap.c | 2 +
drivers/net/ppp/ppp_generic.c | 20 ++++++++
drivers/net/tun.c | 7 +++
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 3 --
drivers/staging/panel/panel.c | 23 +++++++--
drivers/target/iscsi/iscsi_target.c | 19 +++----
drivers/target/target_core_tpg.c | 4 +-
drivers/target/target_core_transport.c | 4 +-
drivers/usb/misc/usbtest.c | 5 +-
include/linux/netdevice.h | 3 ++
include/net/inet_sock.h | 8 ++-
include/net/tcp.h | 6 +--
include/target/target_core_base.h | 1 +
net/core/dev.c | 6 +--
net/dccp/ipv4.c | 13 +++--
net/ipv4/cipso_ipv4.c | 24 +++------
net/ipv4/inet_connection_sock.c | 9 ++--
net/ipv4/ipip.c | 58 ++++++++++++++++------
net/ipv4/syncookies.c | 2 +-
net/ipv4/tcp_input.c | 2 +-
net/ipv4/tcp_ipv4.c | 21 ++++----
net/ipv4/tcp_output.c | 3 +-
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_gre.c | 11 ++--
net/ipv6/ip6_output.c | 4 +-
net/l2tp/l2tp_ppp.c | 3 ++
net/mac80211/key.c | 53 ++++++++++++++++++--
net/packet/af_packet.c | 24 ++++++---
net/sctp/input.c | 2 +-
net/sctp/socket.c | 32 ++++++++++++
net/tipc/link.c | 28 +++--------
net/tipc/link.h | 1 -
net/unix/diag.c | 2 +
security/keys/Kconfig | 4 ++
sound/core/seq/seq_device.c | 3 ++
41 files changed, 299 insertions(+), 147 deletions(-)
On Thu, Nov 16, 2017 at 08:28:28PM +0000, James Cowgill wrote:
> Hi,
>
> On 16/11/17 19:04, Ben Hutchings wrote:
> > On Wed, 2017-11-15 at 16:50 +0000, James Cowgill wrote:
> >> Since I was a little puzzled as to why keyutils built previously on
> >> mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT:
> >>
> >> commit 20f06ed9f61a185c6dabd662c310bed6189470df
> >> Author: David Howells <dhowells(a)redhat.com>
> >> Date: Wed Jul 27 11:43:37 2016 +0100
> >>
> >> KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
> >>
> >> MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
> >> calling sys_keyctl. The latter will work in a lot of cases, thereby hiding
> >> the issue.
> >>
> >> Now I'm thinking maybe this can be argued as a bugfix for the above
> >> commit and put in upstream 4.9?
> >
> > Greg, please queue up these two for 4.9:
> >
> > 5c2a625937ba arm64: support keyctl() system call in 32-bit mode
> > 47b2c3fff493 security/keys: add CONFIG_KEYS_COMPAT to Kconfig
>
> Sorry, I asked for this in two places. I think it's already queued up
> for 4.9 now.
Well, close, but not quite. The second patch there reverts the first
patch, and adds the "generic" work. As I already handled that in the
merge of the second patch, the first one is not needed, and the end
result should be the same.
So all is good. Or at least I think so, someone verifying I got this
all right would be appreciated :)
thanks,
greg k-h
On Tue, Oct 10, 2017 at 10:31 AM, Julia Lawall <julia.lawall(a)lip6.fr> wrote:
>
>
> On Tue, 10 Oct 2017, Levin, Alexander (Sasha Levin) wrote:
>
>> (Cc'ed Julia)
>>
>> On Mon, Oct 09, 2017 at 09:33:01AM -0700, Laura Abbott wrote:
>> >On 10/06/2017 08:10 PM, Levin, Alexander (Sasha Levin) wrote:
>> >> We are experimenting with using neural network to aid with patch
>> >> selection for stable kernel trees. There are quite a few commits that
>> >> were not marked for stable, but are stable material, and we're trying
>> >> to get them into their appropriate kernel trees.
>> >>
>> >
>> >Apart from the practical which has been covered, I'd be interested
>> >in hearing about the details of how this works if you can share
>> >them.
>>
>> This work is based on Julia's work
>> (https://soarsmu.github.io/papers/icse12-patch.pdf) to identify
>> commits that fix bugs.
>>
>> Essentially, my approach to this is to extract as much information as
>> possbile form the commit, including things such as:
>>
>> - How many times a certain word appeared in the message
>> - Who is the author
>> - Code metrics
>> - etc
>>
>> In my case, I end up with about 30,000 of these "inputs", and train a
>> neural network based on whether a given commit was included in a
>> stable tree or not.
>>
>> This approach has a few drawbacks compared to the one Julia
>> described in her paper:
>>
>> - Not every bug fixing commit ends up in stable (some end up in -rc
>> fixing a bug from the current merge window).
>> - Same as above, but for commits we miss and fail to add to stable.
>> - Sometimes commits get added to stable even though they don't follow
>> the rules at all (security fixes are a simple example).
>>
>> But it does seem to be effective at finding bug fixing commits that
>> should be in stable.
>>
>> At this stage we are still trying to figure out what a "bug fixing"
>> commit really is. For example, an observation we recently made was
>> that the code metrics actually don't have much weight in determining
>> whether a commit should be in stable or not.
>>
>> As we just started, I'm still experimenting with a few approaches, and
>> I belive Julia is waiting for a new student to take over this, so we
>> don't have any big insights to share just yet :)
>
> That's a good summary of the current status. Thanks!
>
> julia
I just started noticing the AUTOSEL tags yesterday and I think that's
a great idea to tag patches, but was there any thought to also putting
something in the commit message this way they're easily identifiable
in the git logs? I think it would be useful if there was some metadata
in the commit message which identified that it was selected through
some automated system. That way if I find a regression and it
identifies one of these commits I can know that maybe it was chosen
incorrectly, and also would allow me to alert the owner of the
selection script to better help refine its selection process.
Otherwise I'd have to track back through the mailing lists to see how
it landed in the stable release.
Just a thought. Also, thank you for trying to improve the stable kernels!
--
Josh
This is the start of the stable review cycle for the 4.4.98 release.
There are 56 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.98-rc1
Colin Ian King <colin.king(a)canonical.com>
PKCS#7: fix unitialized boolean 'want'
Borislav Petkov <bp(a)suse.de>
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
Richard Schütz <rschuetz(a)uni-koblenz.de>
can: c_can: don't indicate triple sampling support for D_CAN
Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de>
can: sun4i: handle overrun in RX FIFO
Ilya Dryomov <idryomov(a)gmail.com>
rbd: use GFP_NOIO for parent stat and data requests
Sinclair Yeh <syeh(a)vmware.com>
drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Input: elan_i2c - add ELAN060C to the ACPI table
Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
MIPS: AR7: Ensure that serial ports are properly set up
Jonas Gorski <jonas.gorski(a)gmail.com>
MIPS: AR7: Defer registration of GPIO
Luis R. Rodriguez <mcgrof(a)kernel.org>
tools: firmware: check for distro fallback udev cancel rule
Luis R. Rodriguez <mcgrof(a)kernel.org>
selftests: firmware: send expected errors to /dev/null
Brian Norris <computersforpeace(a)gmail.com>
selftests: firmware: add empty string and async tests
Brian Norris <computersforpeace(a)gmail.com>
test: firmware_class: report errors properly on failure
Matt Redfearn <matt.redfearn(a)imgtec.com>
MIPS: SMP: Fix deadlock & online race
Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com>
MIPS: Fix race on setting and getting cpu_online_mask
Matt Redfearn <matt.redfearn(a)imgtec.com>
MIPS: SMP: Use a completion event to signal CPU up
Paul Burton <paul.burton(a)mips.com>
MIPS: Fix CM region target definitions
Gustavo A. R. Silva <garsilva(a)embeddedor.com>
MIPS: microMIPS: Fix incorrect mask in insn_table_MM
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Avoid invalid lockdep class warning
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix OSS sysex delivery in OSS emulation
Mark Rutland <mark.rutland(a)arm.com>
ARM: 8720/1: ensure dump_instr() checks addr_limit
Eric Biggers <ebiggers(a)google.com>
KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]
Andrey Ryabinin <aryabinin(a)virtuozzo.com>
crypto: x86/sha1-mb - fix panic due to unaligned access
Li Bin <huawei.libin(a)huawei.com>
workqueue: Fix NULL pointer dereference
Peter Zijlstra <peterz(a)infradead.org>
x86/uaccess, sched/preempt: Verify access_ok() context
Carlo Caione <carlo(a)endlessm.com>
platform/x86: hp-wmi: Do not shadow error values
Carlo Caione <carlo(a)endlessm.com>
platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state
Eric Biggers <ebiggers(a)google.com>
KEYS: trusted: fix writing past end of buffer in trusted_read()
Eric Biggers <ebiggers(a)google.com>
KEYS: trusted: sanitize all key material
Enrico Mioso <mrkiko.rs(a)gmail.com>
cdc_ncm: Set NTB format again after altsetting switch for Huawei devices
Carlo Caione <carlo(a)endlessm.com>
platform/x86: hp-wmi: Fix detection for dock and tablet mode
Vivien Didelot <vivien.didelot(a)savoirfairelinux.com>
net: dsa: select NET_SWITCHDEV
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: issue STARTLAN as first IPA command
Feras Daoud <ferasda(a)mellanox.com>
IB/ipoib: Change list_del to list_del_init in the tx object
Akinobu Mita <akinobu.mita(a)gmail.com>
Input: mpr121 - set missing event capability
Akinobu Mita <akinobu.mita(a)gmail.com>
Input: mpr121 - handle multiple bits change of status register
Gilad Ben-Yossef <gilad(a)benyossef.com>
IPsec: do not ignore crypto err in ah4 input
Liping Zhang <zlpnobody(a)gmail.com>
netfilter: nft_meta: deal with PACKET_LOOPBACK in netdev family
William wu <wulf(a)rock-chips.com>
usb: hcd: initialize hcd->flags to 0 when rm hcd
Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
serial: sh-sci: Fix register offsets for the IRDA serial port
Volodymyr Bendiuga <volodymyr.bendiuga(a)gmail.com>
phy: increase size of MII_BUS_ID_SIZE and bus_id
David Lechner <david(a)lechnology.com>
dt-bindings: Add vendor prefix for LEGO
David Lechner <david(a)lechnology.com>
dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
Alison Schofield <amsfield22(a)gmail.com>
iio: trigger: free trigger resource correctly
Li Zhong <zhong(a)linux.vnet.ibm.com>
crypto: vmx - disable preemption to enable vsx in aes_ctr.c
Tony Lindgren <tony(a)atomide.com>
ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
Valentin Longchamp <valentin.longchamp(a)keymile.com>
powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
Nate Watterson <nwatters(a)codeaurora.org>
iommu/arm-smmu-v3: Clear prior settings when updating STEs
Li Zhong <zhong(a)linux.vnet.ibm.com>
KVM: PPC: Book 3S: XICS: correct the real mode ICP rejecting counter
Noralf Trønnes <noralf(a)tronnes.org>
drm: drm_minor_register(): Clean up debugfs on failure
Harninder Rai <harninder.rai(a)nxp.com>
dt-bindings: clockgen: Add compatible string for LS1012A
Patrick Bruenn <p.bruenn(a)beckhoff.com>
ARM: dts: imx53-qsb-common: fix FEC pinmux config
Juergen Gross <jgross(a)suse.com>
xen/netback: set default upper limit of tx/rx queues to 8
Jason Gunthorpe <jgunthorpe(a)obsidianresearch.com>
PCI: mvebu: Handle changes to the bridge windows while enabled
Maciej W. Rozycki <macro(a)linux-mips.org>
video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
Lars-Peter Clausen <lars(a)metafoo.de>
adv7604: Initialize drive strength to default when using DT
-------------
Diffstat:
Documentation/devicetree/bindings/arm/davinci.txt | 4 +
.../devicetree/bindings/clock/qoriq-clock.txt | 1 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
Makefile | 4 +-
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++--
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/kernel/traps.c | 28 ++++--
arch/mips/ar7/platform.c | 5 +
arch/mips/ar7/prom.c | 2 -
arch/mips/include/asm/mips-cm.h | 4 +-
arch/mips/kernel/process.c | 4 +-
arch/mips/kernel/smp.c | 29 ++++--
arch/mips/mm/uasm-micromips.c | 2 +-
arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4 +
arch/powerpc/kvm/book3s_hv_rm_xics.c | 5 +-
arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 -
arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 12 +--
arch/x86/include/asm/uaccess.h | 14 ++-
arch/x86/oprofile/op_model_ppro.c | 4 +-
crypto/asymmetric_keys/pkcs7_parser.c | 2 +-
drivers/block/rbd.c | 4 +-
drivers/crypto/vmx/aes_ctr.c | 6 ++
drivers/gpu/drm/drm_drv.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/iio/trigger/iio-trig-interrupt.c | 8 +-
drivers/iio/trigger/iio-trig-sysfs.c | 2 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +-
drivers/input/keyboard/mpr121_touchkey.c | 24 +++--
drivers/input/mouse/elan_i2c_core.c | 1 +
drivers/iommu/arm-smmu-v3.c | 10 +-
drivers/media/i2c/adv7604.c | 3 +
drivers/net/can/c_can/c_can_pci.c | 1 -
drivers/net/can/c_can/c_can_platform.c | 1 -
drivers/net/can/sun4i_can.c | 12 ++-
drivers/net/usb/cdc_ncm.c | 28 ++++++
drivers/net/usb/huawei_cdc_ncm.c | 6 ++
drivers/net/xen-netback/netback.c | 6 +-
drivers/pci/host/pci-mvebu.c | 101 ++++++++++++---------
drivers/platform/x86/hp-wmi.c | 60 +++++++-----
drivers/s390/net/qeth_core.h | 1 -
drivers/s390/net/qeth_core_main.c | 21 ++++-
drivers/s390/net/qeth_l2_main.c | 15 ---
drivers/s390/net/qeth_l3_main.c | 15 ---
drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 +-
drivers/tty/serial/sh-sci.c | 17 ++--
drivers/usb/core/hcd.c | 1 +
drivers/video/fbdev/pmag-ba-fb.c | 2 +-
include/linux/phy.h | 8 +-
include/linux/preempt.h | 21 +++--
include/linux/usb/cdc_ncm.h | 1 +
include/sound/seq_kernel.h | 3 +-
kernel/workqueue_internal.h | 3 +-
lib/asn1_decoder.c | 4 +-
lib/test_firmware.c | 11 ++-
net/dsa/Kconfig | 5 +-
net/ipv4/ah4.c | 3 +
net/netfilter/nft_meta.c | 28 +++++-
security/keys/trusted.c | 71 +++++++--------
sound/core/seq/oss/seq_oss_midi.c | 4 +-
sound/core/seq/oss/seq_oss_readq.c | 29 ++++++
sound/core/seq/oss/seq_oss_readq.h | 2 +
tools/testing/selftests/firmware/fw_filesystem.sh | 10 +-
tools/testing/selftests/firmware/fw_userhelper.sh | 28 +++++-
63 files changed, 468 insertions(+), 265 deletions(-)
I've cc'ed some folks in hopes to get this resolved upstream.
Either way, 4.1's EoL was previously moved to about 6 months from now,
so hopefully we'll have more than enough time to get this resolved.
On Sat, Nov 11, 2017 at 10:13:55PM +0000, Tuncer Ayaz wrote:
>The predicament I'm in on my machines is that ever since drm-intel has
>implemented atomic modesetting, there's a list regressions caused by
>those fundamental architecture changes and the code churn it implied.
>This means 4.1 is (from what I can tell) the last kernel before atomic
>modesetting was added and the only kernel free of all those issues
>which necessitate trying out various combinations of flags on the
>kernel cmdline.
>
>For instance, right now I'm trying 4.13.12 with these flags:
>video=SVIDEO-1:d
>i915.semaphores=1
>i915.enable_rc6=0
>i915.enable_psr=0
>intel_iommu=igfx_off
>
>PS: I'm kinda confused how anyone uses DMAR with VT-d when it's known
>to be buggy.
>
>The flags seem to decrease the chances of provoking the bugs, but after a
>day of running Xorg, it's possible to still hit the RCS0 GPU hangs.
>
>If you don't pass video=SVIDEO-1:d, then atomic's flip_done times out
>on boot or exit to VT console. It's good that other people have the same
>issues and have been following the bugzilla tickets, and con confirm
>the results.
>
>I'm kinda glad I don't have a machine that's newer than Sandybridge
>since that means I can use 4.1, though it's not a long-term solution,
>and the plan is for the reported bugzilla tickets to be resolved at
>some point, or me switching away from Intel GPUs, which might be
>doable if I save money and get an AMD APU laptop next summer and
>switch my desktop to a discrete GPU.
>
>For example:
>https://bugs.freedesktop.org/show_bug.cgi?id=101237
>https://bugs.freedesktop.org/show_bug.cgi?id=103076
>https://bbs.archlinux.org/viewtopic.php?id=218581&p=3
>https://bugs.archlinux.org/task/51703
>
>So, since 4.4, 4.9 and 4.12, drm-tip are still regressive,
>I wanted to ask if you considered pushing back 4.1's EOL.
>
>Given a look at bugzilla, I have the impression that those issues will
>need at least another year before they're fixed, since most of them
>have been sitting there for many, many months. I suspect the Intel DRM
>team doesn't have the bandwidth to address the issues in a timely
>fashion while still adding upbringing for new GPUs and features
>(fences, etc.).
>
>The generic modesetting DDX and Wayland are less susceptible to the
>GPU hangs, but can be made to provoke it if tried long enough.
>However, the modesetting DDX tears heavily and is about to gain atomic
>modesetting in the next Xorg release, so will suffer from the same
>easy GPU hang likelihood.
>
>Prior to SandyBridge there was zero tearing but beginning with
>SandyBridge xf86-video-intel's TearFree=TRUE is the only reliable way
>to fix Xorg tearing.
>
>I do appreciate you maintaining 4.1 so far and hate to admit that I'm
>reliant on it on more than two machines, before and after Sandybridge,
>exluding those machines which need a newer kernel. I also understand
>how much work this is and since I'm not using Linux professionally for
>a product, I can't offer compensation for your time. I can only offer
>to collect and point you at a list of DRM bugs for validation of my
>claims.
--
Thanks,
Sasha
The rps_resp buffer in ata_device is a DMA target, but it isn't
explicitly cacheline aligned. Due to this, adjacent fields can be
overwritten with stale data from memory on non-coherent architectures.
As a result, the kernel is sometimes unable to communicate with an
SATA device behind a SAS expander.
Fix this by ensuring that the rps_resp buffer is cacheline aligned.
This issue is similar to that fixed by Commit 84bda12af31f93 ("libata:
align ap->sector_buf") and Commit 4ee34ea3a12396f35b26 ("libata: Align
ata_device's id on a cacheline").
Cc: stable(a)vger.kernel.org
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
---
include/scsi/libsas.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
index 0f9cbf9..6df6fe0 100644
--- a/include/scsi/libsas.h
+++ b/include/scsi/libsas.h
@@ -159,11 +159,11 @@ struct expander_device {
struct sata_device {
unsigned int class;
- struct smp_resp rps_resp; /* report_phy_sata_resp */
u8 port_no; /* port number, if this is a PM (Port) */
struct ata_port *ap;
struct ata_host ata_host;
+ struct smp_resp rps_resp ____cacheline_aligned; /* report_phy_sata_resp */
u8 fis[ATA_RESP_FIS_SIZE];
};
--
2.7.0
The patch titled
Subject: mm/page_ext.c: check if page_ext is not prepared
has been removed from the -mm tree. Its filename was
mm-page_ext-check-if-page_ext-is-not-prepared.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Jaewon Kim <jaewon31.kim(a)samsung.com>
Subject: mm/page_ext.c: check if page_ext is not prepared
online_page_ext() and page_ext_init() allocate page_ext for each section,
but they do not allocate if the first PFN is !pfn_present(pfn) or
!pfn_valid(pfn). Then section->page_ext remains as NULL. lookup_page_ext
checks NULL only if CONFIG_DEBUG_VM is enabled. For a valid PFN,
__set_page_owner will try to get page_ext through lookup_page_ext.
Without CONFIG_DEBUG_VM lookup_page_ext will misuse NULL pointer as value
0. This incurrs invalid address access.
This is the panic example when PFN 0x100000 is not valid but PFN 0x13FC00
is being used for page_ext. section->page_ext is NULL, get_entry returned
invalid page_ext address as 0x1DFA000 for a PFN 0x13FC00.
To avoid this panic, CONFIG_DEBUG_VM should be removed so that page_ext
will be checked at all times.
<1>[ 11.618085] Unable to handle kernel paging request at virtual address 01dfa014
<1>[ 11.618140] pgd = ffffffc0c6dc9000
<1>[ 11.618174] [01dfa014] *pgd=0000000000000000, *pud=0000000000000000
<4>[ 11.618240] ------------[ cut here ]------------
<2>[ 11.618278] Kernel BUG at ffffff80082371e0 [verbose debug info unavailable]
<0>[ 11.618338] Internal error: Oops: 96000045 [#1] PREEMPT SMP
<4>[ 11.618381] Modules linked in:
<4>[ 11.618524] task: ffffffc0c6ec9180 task.stack: ffffffc0c6f40000
<4>[ 11.618569] PC is at __set_page_owner+0x48/0x78
<4>[ 11.618607] LR is at __set_page_owner+0x44/0x78
<4>[ 11.626025] [<ffffff80082371e0>] __set_page_owner+0x48/0x78
<4>[ 11.626071] [<ffffff80081df9f0>] get_page_from_freelist+0x880/0x8e8
<4>[ 11.626118] [<ffffff80081e00a4>] __alloc_pages_nodemask+0x14c/0xc48
<4>[ 11.626165] [<ffffff80081e610c>] __do_page_cache_readahead+0xdc/0x264
<4>[ 11.626214] [<ffffff80081d8824>] filemap_fault+0x2ac/0x550
<4>[ 11.626259] [<ffffff80082e5cf8>] ext4_filemap_fault+0x3c/0x58
<4>[ 11.626305] [<ffffff800820a2f8>] __do_fault+0x80/0x120
<4>[ 11.626347] [<ffffff800820eb4c>] handle_mm_fault+0x704/0xbb0
<4>[ 11.626393] [<ffffff800809ba70>] do_page_fault+0x2e8/0x394
<4>[ 11.626437] [<ffffff8008080be4>] do_mem_abort+0x88/0x124
Pre-4.7 kernels also need f86e427197 ("mm: check the return value of
lookup_page_ext for all call sites").
Link: http://lkml.kernel.org/r/20171107094131.14621-1-jaewon31.kim@samsung.com
Fixes: eefa864b701d ("mm/page_ext: resurrect struct page extending code for debugging")
Signed-off-by: Jaewon Kim <jaewon31.kim(a)samsung.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Joonsoo Kim <js1304(a)gmail.com>
Cc: <stable(a)vger.kernel.org> [depends on f86e427197, see above]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_ext.c | 4 ----
1 file changed, 4 deletions(-)
diff -puN mm/page_ext.c~mm-page_ext-check-if-page_ext-is-not-prepared mm/page_ext.c
--- a/mm/page_ext.c~mm-page_ext-check-if-page_ext-is-not-prepared
+++ a/mm/page_ext.c
@@ -125,7 +125,6 @@ struct page_ext *lookup_page_ext(struct
struct page_ext *base;
base = NODE_DATA(page_to_nid(page))->node_page_ext;
-#if defined(CONFIG_DEBUG_VM)
/*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -134,7 +133,6 @@ struct page_ext *lookup_page_ext(struct
*/
if (unlikely(!base))
return NULL;
-#endif
index = pfn - round_down(node_start_pfn(page_to_nid(page)),
MAX_ORDER_NR_PAGES);
return get_entry(base, index);
@@ -199,7 +197,6 @@ struct page_ext *lookup_page_ext(struct
{
unsigned long pfn = page_to_pfn(page);
struct mem_section *section = __pfn_to_section(pfn);
-#if defined(CONFIG_DEBUG_VM)
/*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -208,7 +205,6 @@ struct page_ext *lookup_page_ext(struct
*/
if (!section->page_ext)
return NULL;
-#endif
return get_entry(section->page_ext, pfn);
}
_
Patches currently in -mm which might be from jaewon31.kim(a)samsung.com are
The patch titled
Subject: mm/page_alloc.c: broken deferred calculation
has been removed from the -mm tree. Its filename was
mm-broken-deferred-calculation.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Subject: mm/page_alloc.c: broken deferred calculation
In reset_deferred_meminit() we determine number of pages that must not be
deferred. We initialize pages for at least 2G of memory, but also pages
for reserved memory in this node.
The reserved memory is determined in this function:
memblock_reserved_memory_within(), which operates over physical addresses,
and returns size in bytes. However, reset_deferred_meminit() assumes that
that this function operates with pfns, and returns page count.
The result is that in the best case machine boots slower than expected due
to initializing more pages than needed in single thread, and in the worst
case panics because fewer than needed pages are initialized early.
Link: http://lkml.kernel.org/r/20171021011707.15191-1-pasha.tatashin@oracle.com
Fixes: 864b9a393dcb ("mm: consider memblock reservations for deferred memory initialization sizing")
Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/mmzone.h | 3 ++-
mm/page_alloc.c | 27 ++++++++++++++++++---------
2 files changed, 20 insertions(+), 10 deletions(-)
diff -puN include/linux/mmzone.h~mm-broken-deferred-calculation include/linux/mmzone.h
--- a/include/linux/mmzone.h~mm-broken-deferred-calculation
+++ a/include/linux/mmzone.h
@@ -700,7 +700,8 @@ typedef struct pglist_data {
* is the first PFN that needs to be initialised.
*/
unsigned long first_deferred_pfn;
- unsigned long static_init_size;
+ /* Number of non-deferred pages */
+ unsigned long static_init_pgcnt;
#endif /* CONFIG_DEFERRED_STRUCT_PAGE_INIT */
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
diff -puN mm/page_alloc.c~mm-broken-deferred-calculation mm/page_alloc.c
--- a/mm/page_alloc.c~mm-broken-deferred-calculation
+++ a/mm/page_alloc.c
@@ -291,28 +291,37 @@ EXPORT_SYMBOL(nr_online_nodes);
int page_group_by_mobility_disabled __read_mostly;
#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
+
+/*
+ * Determine how many pages need to be initialized durig early boot
+ * (non-deferred initialization).
+ * The value of first_deferred_pfn will be set later, once non-deferred pages
+ * are initialized, but for now set it ULONG_MAX.
+ */
static inline void reset_deferred_meminit(pg_data_t *pgdat)
{
- unsigned long max_initialise;
- unsigned long reserved_lowmem;
+ phys_addr_t start_addr, end_addr;
+ unsigned long max_pgcnt;
+ unsigned long reserved;
/*
* Initialise at least 2G of a node but also take into account that
* two large system hashes that can take up 1GB for 0.25TB/node.
*/
- max_initialise = max(2UL << (30 - PAGE_SHIFT),
- (pgdat->node_spanned_pages >> 8));
+ max_pgcnt = max(2UL << (30 - PAGE_SHIFT),
+ (pgdat->node_spanned_pages >> 8));
/*
* Compensate the all the memblock reservations (e.g. crash kernel)
* from the initial estimation to make sure we will initialize enough
* memory to boot.
*/
- reserved_lowmem = memblock_reserved_memory_within(pgdat->node_start_pfn,
- pgdat->node_start_pfn + max_initialise);
- max_initialise += reserved_lowmem;
+ start_addr = PFN_PHYS(pgdat->node_start_pfn);
+ end_addr = PFN_PHYS(pgdat->node_start_pfn + max_pgcnt);
+ reserved = memblock_reserved_memory_within(start_addr, end_addr);
+ max_pgcnt += PHYS_PFN(reserved);
- pgdat->static_init_size = min(max_initialise, pgdat->node_spanned_pages);
+ pgdat->static_init_pgcnt = min(max_pgcnt, pgdat->node_spanned_pages);
pgdat->first_deferred_pfn = ULONG_MAX;
}
@@ -339,7 +348,7 @@ static inline bool update_defer_init(pg_
if (zone_end < pgdat_end_pfn(pgdat))
return true;
(*nr_initialised)++;
- if ((*nr_initialised > pgdat->static_init_size) &&
+ if ((*nr_initialised > pgdat->static_init_pgcnt) &&
(pfn & (PAGES_PER_SECTION - 1)) == 0) {
pgdat->first_deferred_pfn = pfn;
return false;
_
Patches currently in -mm which might be from pasha.tatashin(a)oracle.com are
sparc64-ng4-memset-32-bits-overflow.patch
The patch titled
Subject: mm, swap: fix false error message in __swp_swapcount()
has been removed from the -mm tree. Its filename was
mm-swap-fix-false-error-message-in-__swp_swapcount.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap: fix false error message in __swp_swapcount()
When a page fault occurs for a swap entry, the physical swap readahead
(not the VMA base swap readahead) may readahead several swap entries after
the fault swap entry. The readahead algorithm calculates some of the swap
entries to readahead via increasing the offset of the fault swap entry
without checking whether they are beyond the end of the swap device and it
relys on the __swp_swapcount() and swapcache_prepare() to check it.
Although __swp_swapcount() checks for the swap entry passed in, it will
complain with the error message as follow for the expected invalid swap
entry. This may make the end users confused.
swap_info_get: Bad swap offset entry 0200f8a7
To fix the false error message, the swap entry checking is added in
swapin_readahead() to avoid to pass the out-of-bound swap entries and the
swap entry reserved for the swap header to __swp_swapcount() and
swapcache_prepare().
Link: http://lkml.kernel.org/r/20171102054225.22897-1-ying.huang@intel.com
Fixes: e8c26ab60598 ("mm/swap: skip readahead for unreferenced swap slots")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Christian Kujau <lists(a)nerdbynature.de>
Acked-by: Minchan Kim <minchan(a)kernel.org>
Suggested-by: Minchan Kim <minchan(a)kernel.org>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/swap_state.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN mm/swap_state.c~mm-swap-fix-false-error-message-in-__swp_swapcount mm/swap_state.c
--- a/mm/swap_state.c~mm-swap-fix-false-error-message-in-__swp_swapcount
+++ a/mm/swap_state.c
@@ -559,6 +559,7 @@ struct page *swapin_readahead(swp_entry_
unsigned long offset = entry_offset;
unsigned long start_offset, end_offset;
unsigned long mask;
+ struct swap_info_struct *si = swp_swap_info(entry);
struct blk_plug plug;
bool do_poll = true, page_allocated;
@@ -572,6 +573,8 @@ struct page *swapin_readahead(swp_entry_
end_offset = offset | mask;
if (!start_offset) /* First page is swap header. */
start_offset++;
+ if (end_offset >= si->max)
+ end_offset = si->max - 1;
blk_start_plug(&plug);
for (offset = start_offset; offset <= end_offset ; offset++) {
_
Patches currently in -mm which might be from huang.ying.caritas(a)gmail.com are
The patch titled
Subject: ocfs2: should wait dio before inode lock in ocfs2_setattr()
has been removed from the -mm tree. Its filename was
ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: alex chen <alex.chen(a)huawei.com>
Subject: ocfs2: should wait dio before inode lock in ocfs2_setattr()
we should wait dio requests to finish before inode lock in
ocfs2_setattr(), otherwise the following deadlock will happen:
process 1 process 2 process 3
truncate file 'A' end_io of writing file 'A' receiving the bast messages
ocfs2_setattr
ocfs2_inode_lock_tracker
ocfs2_inode_lock_full
inode_dio_wait
__inode_dio_wait
-->waiting for all dio
requests finish
dlm_proxy_ast_handler
dlm_do_local_bast
ocfs2_blocking_ast
ocfs2_generic_handle_bast
set OCFS2_LOCK_BLOCKED flag
dio_end_io
dio_bio_end_aio
dio_complete
ocfs2_dio_end_io
ocfs2_dio_end_io_write
ocfs2_inode_lock
__ocfs2_cluster_lock
ocfs2_wait_for_mask
-->waiting for OCFS2_LOCK_BLOCKED
flag to be cleared, that is waiting
for 'process 1' unlocking the inode lock
inode_dio_end
-->here dec the i_dio_count, but will never
be called, so a deadlock happened.
Link: http://lkml.kernel.org/r/59F81636.70508@huawei.com
Signed-off-by: Alex Chen <alex.chen(a)huawei.com>
Reviewed-by: Jun Piao <piaojun(a)huawei.com>
Reviewed-by: Joseph Qi <jiangqi903(a)gmail.com>
Acked-by: Changwei Ge <ge.changwei(a)h3c.com>
Cc: Mark Fasheh <mfasheh(a)versity.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/ocfs2/file.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff -puN fs/ocfs2/file.c~ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr fs/ocfs2/file.c
--- a/fs/ocfs2/file.c~ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr
+++ a/fs/ocfs2/file.c
@@ -1161,6 +1161,13 @@ int ocfs2_setattr(struct dentry *dentry,
}
size_change = S_ISREG(inode->i_mode) && attr->ia_valid & ATTR_SIZE;
if (size_change) {
+ /*
+ * Here we should wait dio to finish before inode lock
+ * to avoid a deadlock between ocfs2_setattr() and
+ * ocfs2_dio_end_io_write()
+ */
+ inode_dio_wait(inode);
+
status = ocfs2_rw_lock(inode, 1);
if (status < 0) {
mlog_errno(status);
@@ -1200,8 +1207,6 @@ int ocfs2_setattr(struct dentry *dentry,
if (status)
goto bail_unlock;
- inode_dio_wait(inode);
-
if (i_size_read(inode) >= attr->ia_size) {
if (ocfs2_should_order_data(inode)) {
status = ocfs2_begin_ordered_truncate(inode,
_
Patches currently in -mm which might be from alex.chen(a)huawei.com are
The patch titled
Subject: ocfs2: fix cluster hang after a node dies
has been removed from the -mm tree. Its filename was
ocfs2-fix-cluster-hang-after-a-node-dies.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Changwei Ge <ge.changwei(a)h3c.com>
Subject: ocfs2: fix cluster hang after a node dies
When a node dies, other live nodes have to choose a new master for an
existed lock resource mastered by the dead node.
As for ocfs2/dlm implementation, this is done by function -
dlm_move_lockres_to_recovery_list which marks those lock rsources as
DLM_LOCK_RES_RECOVERING and manages them via a list from which DLM changes
lock resource's master later.
So without invoking dlm_move_lockres_to_recovery_list, no master will be
choosed after dlm recovery accomplishment since no lock resource can be
found through ::resource list.
What's worse is that if DLM_LOCK_RES_RECOVERING is not marked for lock
resources mastered a dead node, it will break up synchronization among
nodes.
So invoke dlm_move_lockres_to_recovery_list again.
Fixs: 'commit ee8f7fcbe638 ("ocfs2/dlm: continue to purge recovery lockres when recovery master goes down")'
Link: http://lkml.kernel.org/r/63ADC13FD55D6546B7DECE290D39E373CED6E0F9@H3CMLB14-…
Signed-off-by: Changwei Ge <ge.changwei(a)h3c.com>
Reported-by: Vitaly Mayatskih <v.mayatskih(a)gmail.com>
Tested-by: Vitaly Mayatskikh <v.mayatskih(a)gmail.com>
Cc: Mark Fasheh <mfasheh(a)versity.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: Joseph Qi <jiangqi903(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/ocfs2/dlm/dlmrecovery.c | 1 +
1 file changed, 1 insertion(+)
diff -puN fs/ocfs2/dlm/dlmrecovery.c~ocfs2-fix-cluster-hang-after-a-node-dies fs/ocfs2/dlm/dlmrecovery.c
--- a/fs/ocfs2/dlm/dlmrecovery.c~ocfs2-fix-cluster-hang-after-a-node-dies
+++ a/fs/ocfs2/dlm/dlmrecovery.c
@@ -2419,6 +2419,7 @@ static void dlm_do_local_recovery_cleanu
dlm_lockres_put(res);
continue;
}
+ dlm_move_lockres_to_recovery_list(dlm, res);
} else if (res->owner == dlm->node_num) {
dlm_free_dead_locks(dlm, res, dead_node);
__dlm_lockres_calc_usage(dlm, res);
_
Patches currently in -mm which might be from ge.changwei(a)h3c.com are
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent codec node was also prematurely freed.
Fixes: 4d50934abd22 ("ASoC: da7218: Add da7218 codec driver")
Cc: stable <stable(a)vger.kernel.org> # 4.5
Cc: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
sound/soc/codecs/da7218.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c
index b2d42ec1dcd9..56564ce90cb6 100644
--- a/sound/soc/codecs/da7218.c
+++ b/sound/soc/codecs/da7218.c
@@ -2520,7 +2520,7 @@ static struct da7218_pdata *da7218_of_to_pdata(struct snd_soc_codec *codec)
}
if (da7218->dev_id == DA7218_DEV_ID) {
- hpldet_np = of_find_node_by_name(np, "da7218_hpldet");
+ hpldet_np = of_get_child_by_name(np, "da7218_hpldet");
if (!hpldet_np)
return pdata;
--
2.15.0
a9df21e34b42 ("dmaengine: dmatest: warn user when dma test times out")
for 4.14-stable (applies cleanly)
for 4.13-stable (applies cleanly)
This should be included since it warns the user that the kernel stack memory may
have been corrupted due to a fault DMA callback.
I could also backport for older 4.x kernels if you think it would be useful.
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
This is the start of the stable review cycle for the 4.13.14 release.
There are 44 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat Nov 18 17:28:05 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.14-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.13.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.13.14-rc1
Adam Wallis <awallis(a)codeaurora.org>
dmaengine: dmatest: warn user when dma test times out
Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
EDAC, sb_edac: Don't create a second memory controller if HA1 is not present
Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Input: ims-psu - check if CDC union descriptor is sane
Alan Stern <stern(a)rowland.harvard.edu>
usb: usbtest: fix NULL pointer dereference
Johannes Berg <johannes.berg(a)intel.com>
mac80211: don't compare TKIP TX MIC key in reinstall prevention
Jason A. Donenfeld <Jason(a)zx2c4.com>
mac80211: use constant time comparison with keys
Johannes Berg <johannes.berg(a)intel.com>
mac80211: accept key reinstall without changing anything
Eric Dumazet <edumazet(a)google.com>
tcp: fix tcp_mtu_probe() vs highest_sack
Eric Dumazet <edumazet(a)google.com>
ipv6: addrconf: increment ifp refcount before ipv6_del_addr()
Craig Gallek <kraig(a)google.com>
tun/tap: sanitize TUNSETSNDBUF input
Guillaume Nault <g.nault(a)alphalink.fr>
l2tp: hold tunnel in pppol2tp_connect()
Cong Wang <xiyou.wangcong(a)gmail.com>
net_sched: avoid matching qdisc with zero handle
Xin Long <lucien.xin(a)gmail.com>
sctp: reset owner sk for data chunks on out queues when migrating a sock
Julien Gomes <julien(a)arista.com>
tun: allow positive return values on dev_get_valid_name() call
Girish Moodalbail <girish.moodalbail(a)oracle.com>
tap: reference to KVA of an unloaded module causes kernel panic
Eric Dumazet <edumazet(a)google.com>
tcp: refresh tp timestamp before tcp_mtu_probe()
Xin Long <lucien.xin(a)gmail.com>
ip6_gre: update dst pmtu if dev mtu has been updated by toobig in __gre6_xmit
Xin Long <lucien.xin(a)gmail.com>
ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
Xin Long <lucien.xin(a)gmail.com>
ipip: only increase err_count for some certain type icmp in ipip_err
Or Gerlitz <ogerlitz(a)mellanox.com>
net/mlx5e: Properly deal with encap flows add/del under neigh update
Moshe Shemesh <moshe(a)mellanox.com>
net/mlx5: Fix health work queue spin lock to IRQ safe
Girish Moodalbail <girish.moodalbail(a)oracle.com>
tap: double-free in error path in tap_open()
Andrei Vagin <avagin(a)openvz.org>
net/unix: don't show information about sockets from other namespaces
Vivien Didelot <vivien.didelot(a)savoirfairelinux.com>
net: dsa: check master device before put
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix other lockdep splats accessing ireq_opt
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix lockdep splat in inet_csk_route_req()
Laszlo Toth <laszlth(a)gmail.com>
sctp: full support for ipv6 ip_nonlocal_bind & IP_FREEBIND
Eric Dumazet <edumazet(a)google.com>
ipv6: flowlabel: do not leave opt->tot_len with garbage
Craig Gallek <kraig(a)google.com>
soreuseport: fix initialization race
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
net: bridge: fix returning of vlan range op errors
Stefano Brivio <sbrivio(a)redhat.com>
geneve: Fix function matching VNI and tunnel ID on big-endian
Eric Dumazet <edumazet(a)google.com>
packet: avoid panic in packet_getsockopt()
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: fix ireq->opt races
Xin Long <lucien.xin(a)gmail.com>
sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
Johannes Berg <johannes.berg(a)intel.com>
netlink: fix netlink_ack() extack race
Cong Wang <xiyou.wangcong(a)gmail.com>
tun: call dev_get_valid_name() before register_netdevice()
Guillaume Nault <g.nault(a)alphalink.fr>
l2tp: check ps->sock before running pppol2tp_session_ioctl()
Sabrina Dubroca <sd(a)queasysnail.net>
macsec: fix memory leaks when skb_to_sgvec fails
Eric Dumazet <edumazet(a)google.com>
net: call cgroup_sk_alloc() earlier in sk_clone_lock()
Jason A. Donenfeld <Jason(a)zx2c4.com>
netlink: do not set cb_running if dump's start() errs
Steffen Klassert <steffen.klassert(a)secunet.com>
ipv6: Fix traffic triggered IPsec connections.
Steffen Klassert <steffen.klassert(a)secunet.com>
ipv4: Fix traffic triggered IPsec connections.
Alexey Kodanev <alexey.kodanev(a)oracle.com>
gso: fix payload length when gso_size is zero
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: fix race in ppp device destruction
-------------
Diffstat:
Makefile | 4 +-
drivers/dma/dmatest.c | 1 +
drivers/edac/sb_edac.c | 9 ++-
drivers/input/misc/ims-pcu.c | 16 ++++-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 89 ++++++++++++++----------
drivers/net/ethernet/mellanox/mlx5/core/health.c | 5 +-
drivers/net/geneve.c | 6 --
drivers/net/ipvlan/ipvtap.c | 4 +-
drivers/net/macsec.c | 2 +
drivers/net/macvtap.c | 4 +-
drivers/net/ppp/ppp_generic.c | 20 ++++++
drivers/net/tap.c | 25 ++++---
drivers/net/tun.c | 7 ++
drivers/usb/misc/usbtest.c | 5 +-
include/linux/if_tap.h | 4 +-
include/linux/netdevice.h | 3 +
include/net/inet_sock.h | 8 ++-
include/net/tcp.h | 6 +-
net/bridge/br_netlink.c | 2 +-
net/core/dev.c | 6 +-
net/core/sock.c | 3 +-
net/core/sock_reuseport.c | 12 +++-
net/dccp/ipv4.c | 13 ++--
net/dsa/dsa2.c | 7 +-
net/ipv4/cipso_ipv4.c | 24 ++-----
net/ipv4/gre_offload.c | 2 +-
net/ipv4/inet_connection_sock.c | 9 ++-
net/ipv4/inet_hashtables.c | 5 +-
net/ipv4/ipip.c | 59 +++++++++++-----
net/ipv4/route.c | 2 +-
net/ipv4/syncookies.c | 2 +-
net/ipv4/tcp_input.c | 2 +-
net/ipv4/tcp_ipv4.c | 21 +++---
net/ipv4/tcp_output.c | 5 +-
net/ipv4/udp.c | 5 +-
net/ipv4/udp_offload.c | 2 +-
net/ipv6/addrconf.c | 1 +
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_gre.c | 20 ++++--
net/ipv6/ip6_offload.c | 2 +-
net/ipv6/ip6_output.c | 4 +-
net/ipv6/route.c | 2 +-
net/l2tp/l2tp_ppp.c | 10 ++-
net/mac80211/key.c | 54 ++++++++++++--
net/netlink/af_netlink.c | 21 +++---
net/packet/af_packet.c | 24 ++++---
net/sched/sch_api.c | 2 +
net/sctp/input.c | 2 +-
net/sctp/ipv6.c | 6 +-
net/sctp/socket.c | 32 +++++++++
net/unix/diag.c | 2 +
51 files changed, 395 insertions(+), 187 deletions(-)
This is a note to let you know that I've just added the patch titled
misc: panel: properly restore atomic counter on error path
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
misc-panel-properly-restore-atomic-counter-on-error-path.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7ddfddb3fc0afb2aa36e89b554f06c901c5fa36f Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w(a)1wt.eu>
Date: Thu, 7 Sep 2017 11:56:40 +0200
Subject: misc: panel: properly restore atomic counter on error path
commit 93dc1774d2a4c7a298d5cdf78cc8acdcb7b1428d upstream.
Commit f4757af ("staging: panel: Fix single-open policy race condition")
introduced in 3.19-rc1 attempted to fix a race condition on the open, but
failed to properly do it and used to exit without restoring the semaphore.
This results in -EBUSY being returned after the first open error until
the module is reloaded or the system restarted (ie: consecutive to a
dual open resulting in -EBUSY or to a permission error).
Fixes: f4757af85 # 3.19-rc1
Cc: Mariusz Gorski <marius.gorski(a)gmail.com>
Signed-off-by: Willy Tarreau <w(a)1wt.eu>
[wt: driver is in misc/panel in 4.9]
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/panel.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
--- a/drivers/misc/panel.c
+++ b/drivers/misc/panel.c
@@ -1423,17 +1423,25 @@ static ssize_t lcd_write(struct file *fi
static int lcd_open(struct inode *inode, struct file *file)
{
+ int ret;
+
+ ret = -EBUSY;
if (!atomic_dec_and_test(&lcd_available))
- return -EBUSY; /* open only once at a time */
+ goto fail; /* open only once at a time */
+ ret = -EPERM;
if (file->f_mode & FMODE_READ) /* device is write-only */
- return -EPERM;
+ goto fail;
if (lcd.must_clear) {
lcd_clear_display();
lcd.must_clear = false;
}
return nonseekable_open(inode, file);
+
+ fail:
+ atomic_inc(&lcd_available);
+ return ret;
}
static int lcd_release(struct inode *inode, struct file *file)
@@ -1696,14 +1704,21 @@ static ssize_t keypad_read(struct file *
static int keypad_open(struct inode *inode, struct file *file)
{
+ int ret;
+
+ ret = -EBUSY;
if (!atomic_dec_and_test(&keypad_available))
- return -EBUSY; /* open only once at a time */
+ goto fail; /* open only once at a time */
+ ret = -EPERM;
if (file->f_mode & FMODE_WRITE) /* device is read-only */
- return -EPERM;
+ goto fail;
keypad_buflen = 0; /* flush the buffer on opening */
return 0;
+ fail:
+ atomic_inc(&keypad_available);
+ return ret;
}
static int keypad_release(struct inode *inode, struct file *file)
Patches currently in stable-queue which might be from w(a)1wt.eu are
queue-4.9/misc-panel-properly-restore-atomic-counter-on-error-path.patch
Hi Greg,
as promised a month ago, here finally come the tested backports of this
fix for 4.9 and 4.4 respectively. This backport is not needed for 3.18
as the regression was introduced in 3.19-rc1.
Cheers,
Willy
This is a note to let you know that I've just added the patch titled
misc: panel: properly restore atomic counter on error path
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
misc-panel-properly-restore-atomic-counter-on-error-path.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 29e391ca59d60b7902b09ed11edbc5c95c372f09 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w(a)1wt.eu>
Date: Thu, 7 Sep 2017 11:56:40 +0200
Subject: misc: panel: properly restore atomic counter on error path
commit 93dc1774d2a4c7a298d5cdf78cc8acdcb7b1428d upstream.
Commit f4757af ("staging: panel: Fix single-open policy race condition")
introduced in 3.19-rc1 attempted to fix a race condition on the open, but
failed to properly do it and used to exit without restoring the semaphore.
This results in -EBUSY being returned after the first open error until
the module is reloaded or the system restarted (ie: consecutive to a
dual open resulting in -EBUSY or to a permission error).
Fixes: f4757af85 # 3.19-rc1
Cc: Mariusz Gorski <marius.gorski(a)gmail.com>
Signed-off-by: Willy Tarreau <w(a)1wt.eu>
[wt: driver is in staging/panel in 4.4]
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/panel/panel.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -1431,17 +1431,25 @@ static ssize_t lcd_write(struct file *fi
static int lcd_open(struct inode *inode, struct file *file)
{
+ int ret;
+
+ ret = -EBUSY;
if (!atomic_dec_and_test(&lcd_available))
- return -EBUSY; /* open only once at a time */
+ goto fail; /* open only once at a time */
+ ret = -EPERM;
if (file->f_mode & FMODE_READ) /* device is write-only */
- return -EPERM;
+ goto fail;
if (lcd.must_clear) {
lcd_clear_display();
lcd.must_clear = false;
}
return nonseekable_open(inode, file);
+
+ fail:
+ atomic_inc(&lcd_available);
+ return ret;
}
static int lcd_release(struct inode *inode, struct file *file)
@@ -1704,14 +1712,21 @@ static ssize_t keypad_read(struct file *
static int keypad_open(struct inode *inode, struct file *file)
{
+ int ret;
+
+ ret = -EBUSY;
if (!atomic_dec_and_test(&keypad_available))
- return -EBUSY; /* open only once at a time */
+ goto fail; /* open only once at a time */
+ ret = -EPERM;
if (file->f_mode & FMODE_WRITE) /* device is read-only */
- return -EPERM;
+ goto fail;
keypad_buflen = 0; /* flush the buffer on opening */
return 0;
+ fail:
+ atomic_inc(&keypad_available);
+ return ret;
}
static int keypad_release(struct inode *inode, struct file *file)
Patches currently in stable-queue which might be from w(a)1wt.eu are
queue-4.4/misc-panel-properly-restore-atomic-counter-on-error-path.patch
This is the start of the stable review cycle for the 3.18.82 release.
There are 20 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat Nov 18 17:27:03 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.82-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.82-rc1
Bart Van Assche <bart.vanassche(a)sandisk.com>
target/iscsi: Fix iSCSI task reassignment handling
Bilal Amarni <bilal.amarni(a)gmail.com>
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
Xin Long <lucien.xin(a)gmail.com>
ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
Xin Long <lucien.xin(a)gmail.com>
ipip: only increase err_count for some certain type icmp in ipip_err
Eric Dumazet <edumazet(a)google.com>
ipv6: flowlabel: do not leave opt->tot_len with garbage
Xin Long <lucien.xin(a)gmail.com>
sctp: reset owner sk for data chunks on out queues when migrating a sock
Julien Gomes <julien(a)arista.com>
tun: allow positive return values on dev_get_valid_name() call
Andrei Vagin <avagin(a)openvz.org>
net/unix: don't show information about sockets from other namespaces
Xin Long <lucien.xin(a)gmail.com>
sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
Cong Wang <xiyou.wangcong(a)gmail.com>
tun: call dev_get_valid_name() before register_netdevice()
Guillaume Nault <g.nault(a)alphalink.fr>
l2tp: check ps->sock before running pppol2tp_session_ioctl()
Eric Dumazet <edumazet(a)google.com>
tcp: fix tcp_mtu_probe() vs highest_sack
Craig Gallek <kraig(a)google.com>
tun/tap: sanitize TUNSETSNDBUF input
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Input: ims-psu - check if CDC union descriptor is sane
Alan Stern <stern(a)rowland.harvard.edu>
usb: usbtest: fix NULL pointer dereference
Johannes Berg <johannes.berg(a)intel.com>
mac80211: don't compare TKIP TX MIC key in reinstall prevention
Jason A. Donenfeld <Jason(a)zx2c4.com>
mac80211: use constant time comparison with keys
Johannes Berg <johannes.berg(a)intel.com>
mac80211: accept key reinstall without changing anything
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Revert "ceph: unlock dangling spinlock in try_flush_caps()"
-------------
Diffstat:
Makefile | 4 +--
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 +++++------
arch/powerpc/Kconfig | 5 ---
arch/s390/Kconfig | 3 --
arch/sparc/Kconfig | 3 --
arch/x86/Kconfig | 4 ---
drivers/input/misc/ims-pcu.c | 16 +++++++--
drivers/net/macvtap.c | 2 ++
drivers/net/tun.c | 7 ++++
drivers/target/iscsi/iscsi_target.c | 19 ++++-------
drivers/usb/misc/usbtest.c | 5 +--
fs/ceph/caps.c | 5 +--
include/linux/netdevice.h | 3 ++
include/net/tcp.h | 6 ++--
include/target/target_core_base.h | 1 +
net/core/dev.c | 6 ++--
net/ipv4/ipip.c | 59 +++++++++++++++++++++++----------
net/ipv4/tcp_output.c | 3 +-
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_gre.c | 11 +++---
net/ipv6/ip6_output.c | 4 +--
net/l2tp/l2tp_ppp.c | 3 ++
net/mac80211/key.c | 53 +++++++++++++++++++++++++++--
net/sctp/input.c | 2 +-
net/sctp/socket.c | 32 ++++++++++++++++++
net/unix/diag.c | 2 ++
security/keys/Kconfig | 4 +++
27 files changed, 202 insertions(+), 81 deletions(-)
This is a note to let you know that I've just added the patch titled
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
security-keys-add-config_keys_compat-to-kconfig.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 47b2c3fff4932e6fc17ce13d51a43c6969714e20 Mon Sep 17 00:00:00 2001
From: Bilal Amarni <bilal.amarni(a)gmail.com>
Date: Thu, 8 Jun 2017 14:47:26 +0100
Subject: security/keys: add CONFIG_KEYS_COMPAT to Kconfig
From: Bilal Amarni <bilal.amarni(a)gmail.com>
commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 upstream.
CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.
At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.
This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.
[DH: Modified to remove arm64 compat enablement also as requested by Eric
Biggers]
Signed-off-by: Bilal Amarni <bilal.amarni(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Cc: James Cowgill <james.cowgill(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/Kconfig | 5 -----
arch/s390/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
arch/x86/Kconfig | 4 ----
security/keys/Kconfig | 4 ++++
5 files changed, 4 insertions(+), 15 deletions(-)
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1087,11 +1087,6 @@ source "arch/powerpc/Kconfig.debug"
source "security/Kconfig"
-config KEYS_COMPAT
- bool
- depends on COMPAT && KEYS
- default y
-
source "crypto/Kconfig"
config PPC_LIB_RHEAP
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -359,9 +359,6 @@ config COMPAT
config SYSVIPC_COMPAT
def_bool y if COMPAT && SYSVIPC
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
config SMP
def_bool y
prompt "Symmetric multi-processing support"
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -568,9 +568,6 @@ config SYSVIPC_COMPAT
depends on COMPAT && SYSVIPC
default y
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
endmenu
source "net/Kconfig"
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2732,10 +2732,6 @@ config COMPAT_FOR_U64_ALIGNMENT
config SYSVIPC_COMPAT
def_bool y
depends on SYSVIPC
-
-config KEYS_COMPAT
- def_bool y
- depends on KEYS
endif
endmenu
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -20,6 +20,10 @@ config KEYS
If you are unsure as to whether this is required, answer N.
+config KEYS_COMPAT
+ def_bool y
+ depends on COMPAT && KEYS
+
config PERSISTENT_KEYRINGS
bool "Enable register of persistent per-UID keyrings"
depends on KEYS
Patches currently in stable-queue which might be from bilal.amarni(a)gmail.com are
queue-4.9/security-keys-add-config_keys_compat-to-kconfig.patch
This is a note to let you know that I've just added the patch titled
qla2xxx: Fix incorrect tcm_qla2xxx_free_cmd use during TMR ABORT (v2)
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
qla2xxx-fix-incorrect-tcm_qla2xxx_free_cmd-use-during-tmr-abort-v2.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6bcbb3174caa5f1ccc894f8ae077631659d5a629 Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Date: Fri, 30 Jun 2017 00:08:13 -0700
Subject: qla2xxx: Fix incorrect tcm_qla2xxx_free_cmd use during TMR ABORT (v2)
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
commit 6bcbb3174caa5f1ccc894f8ae077631659d5a629 upstream.
This patch drops two incorrect usages of tcm_qla2xxx_free_cmd()
during TMR ABORT within tcm_qla2xxx_handle_data_work() and
tcm_qla2xxx_aborted_task(), which where attempting to dispatch
into workqueue context to do tcm_qla2xxx_complete_free() and
subsequently invoke transport_generic_free_cmd().
This is incorrect because during TMR ABORT target-core will
drop the outstanding se_cmd->cmd_kref references once it has
quiesced the se_cmd via transport_wait_for_tasks(), and in
the case of qla2xxx it should not attempt to do it's own
transport_generic_free_cmd() once the abort has occured.
As reported by Pascal, this was originally manifesting as a
BUG_ON(cmd->cmd_in_wq) in qlt_free_cmd() during TMR ABORT,
with a LIO backend that had sufficently high enough WRITE
latency to trigger a host side TMR ABORT_TASK.
(v2: Drop the qla_tgt_cmd->write_pending_abort_comp changes,
as they will be addressed in a seperate series)
Reported-by: Pascal de Bruijn <p.debruijn(a)unilogic.nl>
Tested-by: Pascal de Bruijn <p.debruijn(a)unilogic.nl>
Cc: Pascal de Bruijn <p.debruijn(a)unilogic.nl>
Reported-by: Lukasz Engel <lukasz.engel(a)softax.pl>
Cc: Lukasz Engel <lukasz.engel(a)softax.pl>
Acked-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Cc: Quinn Tran <quinn.tran(a)cavium.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 33 ---------------------------------
1 file changed, 33 deletions(-)
--- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
+++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
@@ -484,7 +484,6 @@ static int tcm_qla2xxx_handle_cmd(scsi_q
static void tcm_qla2xxx_handle_data_work(struct work_struct *work)
{
struct qla_tgt_cmd *cmd = container_of(work, struct qla_tgt_cmd, work);
- unsigned long flags;
/*
* Ensure that the complete FCP WRITE payload has been received.
@@ -492,17 +491,6 @@ static void tcm_qla2xxx_handle_data_work
*/
cmd->cmd_in_wq = 0;
- spin_lock_irqsave(&cmd->cmd_lock, flags);
- cmd->cmd_flags |= CMD_FLAG_DATA_WORK;
- if (cmd->aborted) {
- cmd->cmd_flags |= CMD_FLAG_DATA_WORK_FREE;
- spin_unlock_irqrestore(&cmd->cmd_lock, flags);
-
- tcm_qla2xxx_free_cmd(cmd);
- return;
- }
- spin_unlock_irqrestore(&cmd->cmd_lock, flags);
-
cmd->vha->tgt_counters.qla_core_ret_ctio++;
if (!cmd->write_data_transferred) {
/*
@@ -682,34 +670,13 @@ static void tcm_qla2xxx_queue_tm_rsp(str
qlt_xmit_tm_rsp(mcmd);
}
-
-#define DATA_WORK_NOT_FREE(_flags) \
- (( _flags & (CMD_FLAG_DATA_WORK|CMD_FLAG_DATA_WORK_FREE)) == \
- CMD_FLAG_DATA_WORK)
static void tcm_qla2xxx_aborted_task(struct se_cmd *se_cmd)
{
struct qla_tgt_cmd *cmd = container_of(se_cmd,
struct qla_tgt_cmd, se_cmd);
- unsigned long flags;
if (qlt_abort_cmd(cmd))
return;
-
- spin_lock_irqsave(&cmd->cmd_lock, flags);
- if ((cmd->state == QLA_TGT_STATE_NEW)||
- ((cmd->state == QLA_TGT_STATE_DATA_IN) &&
- DATA_WORK_NOT_FREE(cmd->cmd_flags)) ) {
-
- cmd->cmd_flags |= CMD_FLAG_DATA_WORK_FREE;
- spin_unlock_irqrestore(&cmd->cmd_lock, flags);
- /* Cmd have not reached firmware.
- * Use this trigger to free it. */
- tcm_qla2xxx_free_cmd(cmd);
- return;
- }
- spin_unlock_irqrestore(&cmd->cmd_lock, flags);
- return;
-
}
static void tcm_qla2xxx_clear_sess_lookup(struct tcm_qla2xxx_lport *,
Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are
queue-4.9/qla2xxx-fix-incorrect-tcm_qla2xxx_free_cmd-use-during-tmr-abort-v2.patch
queue-4.9/target-iscsi-fix-iscsi-task-reassignment-handling.patch
This is a note to let you know that I've just added the patch titled
netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e1bf1687740ce1a3598a1c5e452b852ff2190682 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Wed, 6 Sep 2017 14:39:51 +0200
Subject: netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"
From: Florian Westphal <fw(a)strlen.de>
commit e1bf1687740ce1a3598a1c5e452b852ff2190682 upstream.
This reverts commit 870190a9ec9075205c0fa795a09fa931694a3ff1.
It was not a good idea. The custom hash table was a much better
fit for this purpose.
A fast lookup is not essential, in fact for most cases there is no lookup
at all because original tuple is not taken and can be used as-is.
What needs to be fast is insertion and deletion.
rhlist removal however requires a rhlist walk.
We can have thousands of entries in such a list if source port/addresses
are reused for multiple flows, if this happens removal requests are so
expensive that deletions of a few thousand flows can take several
seconds(!).
The advantages that we got from rhashtable are:
1) table auto-sizing
2) multiple locks
1) would be nice to have, but it is not essential as we have at
most one lookup per new flow, so even a million flows in the bysource
table are not a problem compared to current deletion cost.
2) is easy to add to custom hash table.
I tried to add hlist_node to rhlist to speed up rhltable_remove but this
isn't doable without changing semantics. rhltable_remove_fast will
check that the to-be-deleted object is part of the table and that
requires a list walk that we want to avoid.
Furthermore, using hlist_node increases size of struct rhlist_head, which
in turn increases nf_conn size.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196821
Reported-by: Ivan Babrou <ibobrik(a)gmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/netfilter/nf_conntrack.h | 3
include/net/netfilter/nf_nat.h | 1
net/netfilter/nf_nat_core.c | 132 ++++++++++++++---------------------
3 files changed, 56 insertions(+), 80 deletions(-)
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -17,7 +17,6 @@
#include <linux/bitops.h>
#include <linux/compiler.h>
#include <linux/atomic.h>
-#include <linux/rhashtable.h>
#include <linux/netfilter/nf_conntrack_tcp.h>
#include <linux/netfilter/nf_conntrack_dccp.h>
@@ -101,7 +100,7 @@ struct nf_conn {
possible_net_t ct_net;
#if IS_ENABLED(CONFIG_NF_NAT)
- struct rhlist_head nat_bysource;
+ struct hlist_node nat_bysource;
#endif
/* all members below initialized via memset */
u8 __nfct_init_offset[0];
--- a/include/net/netfilter/nf_nat.h
+++ b/include/net/netfilter/nf_nat.h
@@ -1,6 +1,5 @@
#ifndef _NF_NAT_H
#define _NF_NAT_H
-#include <linux/rhashtable.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netfilter/nf_nat.h>
#include <net/netfilter/nf_conntrack_tuple.h>
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -30,19 +30,17 @@
#include <net/netfilter/nf_conntrack_zones.h>
#include <linux/netfilter/nf_nat.h>
+static DEFINE_SPINLOCK(nf_nat_lock);
+
static DEFINE_MUTEX(nf_nat_proto_mutex);
static const struct nf_nat_l3proto __rcu *nf_nat_l3protos[NFPROTO_NUMPROTO]
__read_mostly;
static const struct nf_nat_l4proto __rcu **nf_nat_l4protos[NFPROTO_NUMPROTO]
__read_mostly;
-struct nf_nat_conn_key {
- const struct net *net;
- const struct nf_conntrack_tuple *tuple;
- const struct nf_conntrack_zone *zone;
-};
-
-static struct rhltable nf_nat_bysource_table;
+static struct hlist_head *nf_nat_bysource __read_mostly;
+static unsigned int nf_nat_htable_size __read_mostly;
+static unsigned int nf_nat_hash_rnd __read_mostly;
inline const struct nf_nat_l3proto *
__nf_nat_l3proto_find(u8 family)
@@ -121,17 +119,19 @@ int nf_xfrm_me_harder(struct net *net, s
EXPORT_SYMBOL(nf_xfrm_me_harder);
#endif /* CONFIG_XFRM */
-static u32 nf_nat_bysource_hash(const void *data, u32 len, u32 seed)
+/* We keep an extra hash for each conntrack, for fast searching. */
+static inline unsigned int
+hash_by_src(const struct net *n, const struct nf_conntrack_tuple *tuple)
{
- const struct nf_conntrack_tuple *t;
- const struct nf_conn *ct = data;
+ unsigned int hash;
+
+ get_random_once(&nf_nat_hash_rnd, sizeof(nf_nat_hash_rnd));
- t = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
/* Original src, to ensure we map it consistently if poss. */
+ hash = jhash2((u32 *)&tuple->src, sizeof(tuple->src) / sizeof(u32),
+ tuple->dst.protonum ^ nf_nat_hash_rnd ^ net_hash_mix(n));
- seed ^= net_hash_mix(nf_ct_net(ct));
- return jhash2((const u32 *)&t->src, sizeof(t->src) / sizeof(u32),
- t->dst.protonum ^ seed);
+ return reciprocal_scale(hash, nf_nat_htable_size);
}
/* Is this tuple already taken? (not by us) */
@@ -187,28 +187,6 @@ same_src(const struct nf_conn *ct,
t->src.u.all == tuple->src.u.all);
}
-static int nf_nat_bysource_cmp(struct rhashtable_compare_arg *arg,
- const void *obj)
-{
- const struct nf_nat_conn_key *key = arg->key;
- const struct nf_conn *ct = obj;
-
- if (!same_src(ct, key->tuple) ||
- !net_eq(nf_ct_net(ct), key->net) ||
- !nf_ct_zone_equal(ct, key->zone, IP_CT_DIR_ORIGINAL))
- return 1;
-
- return 0;
-}
-
-static struct rhashtable_params nf_nat_bysource_params = {
- .head_offset = offsetof(struct nf_conn, nat_bysource),
- .obj_hashfn = nf_nat_bysource_hash,
- .obj_cmpfn = nf_nat_bysource_cmp,
- .nelem_hint = 256,
- .min_size = 1024,
-};
-
/* Only called for SRC manip */
static int
find_appropriate_src(struct net *net,
@@ -219,26 +197,22 @@ find_appropriate_src(struct net *net,
struct nf_conntrack_tuple *result,
const struct nf_nat_range *range)
{
+ unsigned int h = hash_by_src(net, tuple);
const struct nf_conn *ct;
- struct nf_nat_conn_key key = {
- .net = net,
- .tuple = tuple,
- .zone = zone
- };
- struct rhlist_head *hl, *h;
-
- hl = rhltable_lookup(&nf_nat_bysource_table, &key,
- nf_nat_bysource_params);
- rhl_for_each_entry_rcu(ct, h, hl, nat_bysource) {
- nf_ct_invert_tuplepr(result,
- &ct->tuplehash[IP_CT_DIR_REPLY].tuple);
- result->dst = tuple->dst;
+ hlist_for_each_entry_rcu(ct, &nf_nat_bysource[h], nat_bysource) {
+ if (same_src(ct, tuple) &&
+ net_eq(net, nf_ct_net(ct)) &&
+ nf_ct_zone_equal(ct, zone, IP_CT_DIR_ORIGINAL)) {
+ /* Copy source part from reply tuple. */
+ nf_ct_invert_tuplepr(result,
+ &ct->tuplehash[IP_CT_DIR_REPLY].tuple);
+ result->dst = tuple->dst;
- if (in_range(l3proto, l4proto, result, range))
- return 1;
+ if (in_range(l3proto, l4proto, result, range))
+ return 1;
+ }
}
-
return 0;
}
@@ -411,6 +385,7 @@ nf_nat_setup_info(struct nf_conn *ct,
const struct nf_nat_range *range,
enum nf_nat_manip_type maniptype)
{
+ struct net *net = nf_ct_net(ct);
struct nf_conntrack_tuple curr_tuple, new_tuple;
struct nf_conn_nat *nat;
@@ -452,19 +427,16 @@ nf_nat_setup_info(struct nf_conn *ct,
}
if (maniptype == NF_NAT_MANIP_SRC) {
- struct nf_nat_conn_key key = {
- .net = nf_ct_net(ct),
- .tuple = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple,
- .zone = nf_ct_zone(ct),
- };
- int err;
-
- err = rhltable_insert_key(&nf_nat_bysource_table,
- &key,
- &ct->nat_bysource,
- nf_nat_bysource_params);
- if (err)
- return NF_DROP;
+ unsigned int srchash;
+
+ srchash = hash_by_src(net,
+ &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
+ spin_lock_bh(&nf_nat_lock);
+ /* nf_conntrack_alter_reply might re-allocate extension aera */
+ nat = nfct_nat(ct);
+ hlist_add_head_rcu(&ct->nat_bysource,
+ &nf_nat_bysource[srchash]);
+ spin_unlock_bh(&nf_nat_lock);
}
/* It's done. */
@@ -572,9 +544,10 @@ static int nf_nat_proto_clean(struct nf_
* Else, when the conntrack is destoyed, nf_nat_cleanup_conntrack()
* will delete entry from already-freed table.
*/
+ spin_lock_bh(&nf_nat_lock);
+ hlist_del_rcu(&ct->nat_bysource);
ct->status &= ~IPS_NAT_DONE_MASK;
- rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource,
- nf_nat_bysource_params);
+ spin_unlock_bh(&nf_nat_lock);
/* don't delete conntrack. Although that would make things a lot
* simpler, we'd end up flushing all conntracks on nat rmmod.
@@ -699,9 +672,11 @@ EXPORT_SYMBOL_GPL(nf_nat_l3proto_unregis
/* No one using conntrack by the time this called. */
static void nf_nat_cleanup_conntrack(struct nf_conn *ct)
{
- if (ct->status & IPS_SRC_NAT_DONE)
- rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource,
- nf_nat_bysource_params);
+ if (ct->status & IPS_SRC_NAT_DONE) {
+ spin_lock_bh(&nf_nat_lock);
+ hlist_del_rcu(&ct->nat_bysource);
+ spin_unlock_bh(&nf_nat_lock);
+ }
}
static struct nf_ct_ext_type nat_extend __read_mostly = {
@@ -836,13 +811,16 @@ static int __init nf_nat_init(void)
{
int ret;
- ret = rhltable_init(&nf_nat_bysource_table, &nf_nat_bysource_params);
- if (ret)
- return ret;
+ /* Leave them the same for the moment. */
+ nf_nat_htable_size = nf_conntrack_htable_size;
+
+ nf_nat_bysource = nf_ct_alloc_hashtable(&nf_nat_htable_size, 0);
+ if (!nf_nat_bysource)
+ return -ENOMEM;
ret = nf_ct_extend_register(&nat_extend);
if (ret < 0) {
- rhltable_destroy(&nf_nat_bysource_table);
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
printk(KERN_ERR "nf_nat_core: Unable to register extension\n");
return ret;
}
@@ -866,7 +844,7 @@ static int __init nf_nat_init(void)
return 0;
cleanup_extend:
- rhltable_destroy(&nf_nat_bysource_table);
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
nf_ct_extend_unregister(&nat_extend);
return ret;
}
@@ -886,8 +864,8 @@ static void __exit nf_nat_cleanup(void)
for (i = 0; i < NFPROTO_NUMPROTO; i++)
kfree(nf_nat_l4protos[i]);
-
- rhltable_destroy(&nf_nat_bysource_table);
+ synchronize_net();
+ nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size);
}
MODULE_LICENSE("GPL");
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.9/netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.patch
queue-4.9/netfilter-nat-avoid-use-of-nf_conn_nat-extension.patch
This is a note to let you know that I've just added the patch titled
netfilter: nat: avoid use of nf_conn_nat extension
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-nat-avoid-use-of-nf_conn_nat-extension.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6e699867f84c0f358fed233fe6162173aca28e04 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Tue, 28 Mar 2017 10:31:03 +0200
Subject: netfilter: nat: avoid use of nf_conn_nat extension
From: Florian Westphal <fw(a)strlen.de>
commit 6e699867f84c0f358fed233fe6162173aca28e04 upstream.
successful insert into the bysource hash sets IPS_SRC_NAT_DONE status bit
so we can check that instead of presence of nat extension which requires
extra deref.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nf_conntrack_core.c | 2 +-
net/netfilter/nf_nat_core.c | 18 ++++--------------
2 files changed, 5 insertions(+), 15 deletions(-)
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -689,7 +689,7 @@ static int nf_ct_resolve_clash(struct ne
l4proto = __nf_ct_l4proto_find(nf_ct_l3num(ct), nf_ct_protonum(ct));
if (l4proto->allow_clash &&
- !nfct_nat(ct) &&
+ ((ct->status & IPS_NAT_DONE_MASK) == 0) &&
!nf_ct_is_dying(ct) &&
atomic_inc_not_zero(&ct->ct_general.use)) {
nf_ct_acct_merge(ct, ctinfo, (struct nf_conn *)skb->nfct);
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -550,10 +550,6 @@ struct nf_nat_proto_clean {
static int nf_nat_proto_remove(struct nf_conn *i, void *data)
{
const struct nf_nat_proto_clean *clean = data;
- struct nf_conn_nat *nat = nfct_nat(i);
-
- if (!nat)
- return 0;
if ((clean->l3proto && nf_ct_l3num(i) != clean->l3proto) ||
(clean->l4proto && nf_ct_protonum(i) != clean->l4proto))
@@ -564,12 +560,10 @@ static int nf_nat_proto_remove(struct nf
static int nf_nat_proto_clean(struct nf_conn *ct, void *data)
{
- struct nf_conn_nat *nat = nfct_nat(ct);
-
if (nf_nat_proto_remove(ct, data))
return 1;
- if (!nat)
+ if ((ct->status & IPS_SRC_NAT_DONE) == 0)
return 0;
/* This netns is being destroyed, and conntrack has nat null binding.
@@ -705,13 +699,9 @@ EXPORT_SYMBOL_GPL(nf_nat_l3proto_unregis
/* No one using conntrack by the time this called. */
static void nf_nat_cleanup_conntrack(struct nf_conn *ct)
{
- struct nf_conn_nat *nat = nf_ct_ext_find(ct, NF_CT_EXT_NAT);
-
- if (!nat)
- return;
-
- rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource,
- nf_nat_bysource_params);
+ if (ct->status & IPS_SRC_NAT_DONE)
+ rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource,
+ nf_nat_bysource_params);
}
static struct nf_ct_ext_type nat_extend __read_mostly = {
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.9/netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.patch
queue-4.9/netfilter-nat-avoid-use-of-nf_conn_nat-extension.patch
This is a note to let you know that I've just added the patch titled
brcmfmac: remove setting IBSS mode when stopping AP
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
brcmfmac-remove-setting-ibss-mode-when-stopping-ap.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9029679f66d976f8c720eb03c4898274803c9923 Mon Sep 17 00:00:00 2001
From: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
Date: Thu, 18 May 2017 17:22:19 +0800
Subject: brcmfmac: remove setting IBSS mode when stopping AP
From: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
commit 9029679f66d976f8c720eb03c4898274803c9923 upstream.
Upon stopping an AP interface the driver disable INFRA mode effectively
setting the interface in IBSS mode. However, this may affect other
interfaces running in INFRA mode. For instance, if user creates and stops
hostap daemon on virtual interface, then association cannot work on
primary interface because default BSS has been set to IBSS mode in
firmware side. The IBSS mode should be set when cfg80211 changes the
interface.
Reviewed-by: Wright Feng <wright.feng(a)cypress.com>
Signed-off-by: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
[kvalo(a)codeaurora.org: rephased commit log based on discussion]
Signed-off-by: Wright Feng <wright.feng(a)cypress.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Cc: Philipp Rosenberger <p.rosenberger(a)linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ---
1 file changed, 3 deletions(-)
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4754,9 +4754,6 @@ static int brcmf_cfg80211_stop_ap(struct
err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_AP, 0);
if (err < 0)
brcmf_err("setting AP mode failed %d\n", err);
- err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_INFRA, 0);
- if (err < 0)
- brcmf_err("setting INFRA mode failed %d\n", err);
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
brcmf_fil_iovar_int_set(ifp, "mbss", 0);
brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_REGULATORY,
Patches currently in stable-queue which might be from Chi-Hsien.Lin(a)cypress.com are
queue-4.9/brcmfmac-remove-setting-ibss-mode-when-stopping-ap.patch
This is a note to let you know that I've just added the patch titled
tipc: fix link attribute propagation bug
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tipc-fix-link-attribute-propagation-bug.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d01332f1acacc0cb43a61f4244dd2b846d4cd585 Mon Sep 17 00:00:00 2001
From: Richard Alpe <richard.alpe(a)ericsson.com>
Date: Mon, 1 Feb 2016 08:19:56 +0100
Subject: tipc: fix link attribute propagation bug
From: Richard Alpe <richard.alpe(a)ericsson.com>
commit d01332f1acacc0cb43a61f4244dd2b846d4cd585 upstream.
Changing certain link attributes (link tolerance and link priority)
from the TIPC management tool is supposed to automatically take
effect at both endpoints of the affected link.
Currently the media address is not instantiated for the link and is
used uninstantiated when crafting protocol messages designated for the
peer endpoint. This means that changing a link property currently
results in the property being changed on the local machine but the
protocol message designated for the peer gets lost. Resulting in
property discrepancy between the endpoints.
In this patch we resolve this by using the media address from the
link entry and using the bearer transmit function to send it. Hence,
we can now eliminate the redundant function tipc_link_prot_xmit() and
the redundant field tipc_link::media_addr.
Fixes: 2af5ae372a4b (tipc: clean up unused code and structures)
Reviewed-by: Jon Maloy <jon.maloy(a)ericsson.com>
Reported-by: Jason Hu <huzhijiang(a)gmail.com>
Signed-off-by: Richard Alpe <richard.alpe(a)ericsson.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
[backported to 4.4 by Tommi Rantala]
Signed-off-by: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/tipc/link.c | 28 ++++++----------------------
net/tipc/link.h | 1 -
2 files changed, 6 insertions(+), 23 deletions(-)
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1084,25 +1084,6 @@ drop:
return rc;
}
-/*
- * Send protocol message to the other endpoint.
- */
-void tipc_link_proto_xmit(struct tipc_link *l, u32 msg_typ, int probe_msg,
- u32 gap, u32 tolerance, u32 priority)
-{
- struct sk_buff *skb = NULL;
- struct sk_buff_head xmitq;
-
- __skb_queue_head_init(&xmitq);
- tipc_link_build_proto_msg(l, msg_typ, probe_msg, gap,
- tolerance, priority, &xmitq);
- skb = __skb_dequeue(&xmitq);
- if (!skb)
- return;
- tipc_bearer_xmit_skb(l->net, l->bearer_id, skb, l->media_addr);
- l->rcv_unacked = 0;
-}
-
static void tipc_link_build_proto_msg(struct tipc_link *l, int mtyp, bool probe,
u16 rcvgap, int tolerance, int priority,
struct sk_buff_head *xmitq)
@@ -1636,9 +1617,12 @@ int tipc_nl_link_set(struct sk_buff *skb
char *name;
struct tipc_link *link;
struct tipc_node *node;
+ struct sk_buff_head xmitq;
struct nlattr *attrs[TIPC_NLA_LINK_MAX + 1];
struct net *net = sock_net(skb->sk);
+ __skb_queue_head_init(&xmitq);
+
if (!info->attrs[TIPC_NLA_LINK])
return -EINVAL;
@@ -1683,14 +1667,14 @@ int tipc_nl_link_set(struct sk_buff *skb
tol = nla_get_u32(props[TIPC_NLA_PROP_TOL]);
link->tolerance = tol;
- tipc_link_proto_xmit(link, STATE_MSG, 0, 0, tol, 0);
+ tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, tol, 0, &xmitq);
}
if (props[TIPC_NLA_PROP_PRIO]) {
u32 prio;
prio = nla_get_u32(props[TIPC_NLA_PROP_PRIO]);
link->priority = prio;
- tipc_link_proto_xmit(link, STATE_MSG, 0, 0, 0, prio);
+ tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, 0, prio, &xmitq);
}
if (props[TIPC_NLA_PROP_WIN]) {
u32 win;
@@ -1702,7 +1686,7 @@ int tipc_nl_link_set(struct sk_buff *skb
out:
tipc_node_unlock(node);
-
+ tipc_bearer_xmit(net, bearer_id, &xmitq, &node->links[bearer_id].maddr);
return res;
}
--- a/net/tipc/link.h
+++ b/net/tipc/link.h
@@ -153,7 +153,6 @@ struct tipc_stats {
struct tipc_link {
u32 addr;
char name[TIPC_MAX_LINK_NAME];
- struct tipc_media_addr *media_addr;
struct net *net;
/* Management and link supervision data */
Patches currently in stable-queue which might be from richard.alpe(a)ericsson.com are
queue-4.4/tipc-fix-link-attribute-propagation-bug.patch
This is a note to let you know that I've just added the patch titled
target/iscsi: Fix iSCSI task reassignment handling
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-iscsi-fix-iscsi-task-reassignment-handling.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 59b6986dbfcdab96a971f9663221849de79a7556 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)sandisk.com>
Date: Thu, 5 Jan 2017 12:39:57 +0100
Subject: target/iscsi: Fix iSCSI task reassignment handling
From: Bart Van Assche <bart.vanassche(a)sandisk.com>
commit 59b6986dbfcdab96a971f9663221849de79a7556 upstream.
Allocate a task management request structure for all task management
requests, including task reassignment. This change avoids that the
se_tmr->response assignment dereferences an uninitialized se_tmr
pointer.
Reported-by: Moshe David <mdavid(a)infinidat.com>
Signed-off-by: Bart Van Assche <bart.vanassche(a)sandisk.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Cc: Moshe David <mdavid(a)infinidat.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1759,7 +1759,7 @@ iscsit_handle_task_mgt_cmd(struct iscsi_
struct iscsi_tm *hdr;
int out_of_order_cmdsn = 0, ret;
bool sess_ref = false;
- u8 function;
+ u8 function, tcm_function = TMR_UNKNOWN;
hdr = (struct iscsi_tm *) buf;
hdr->flags &= ~ISCSI_FLAG_CMD_FINAL;
@@ -1805,10 +1805,6 @@ iscsit_handle_task_mgt_cmd(struct iscsi_
* LIO-Target $FABRIC_MOD
*/
if (function != ISCSI_TM_FUNC_TASK_REASSIGN) {
-
- u8 tcm_function;
- int ret;
-
transport_init_se_cmd(&cmd->se_cmd, &iscsi_ops,
conn->sess->se_sess, 0, DMA_NONE,
TCM_SIMPLE_TAG, cmd->sense_buffer + 2);
@@ -1844,15 +1840,14 @@ iscsit_handle_task_mgt_cmd(struct iscsi_
return iscsit_add_reject_cmd(cmd,
ISCSI_REASON_BOOKMARK_NO_RESOURCES, buf);
}
-
- ret = core_tmr_alloc_req(&cmd->se_cmd, cmd->tmr_req,
- tcm_function, GFP_KERNEL);
- if (ret < 0)
- return iscsit_add_reject_cmd(cmd,
+ }
+ ret = core_tmr_alloc_req(&cmd->se_cmd, cmd->tmr_req, tcm_function,
+ GFP_KERNEL);
+ if (ret < 0)
+ return iscsit_add_reject_cmd(cmd,
ISCSI_REASON_BOOKMARK_NO_RESOURCES, buf);
- cmd->tmr_req->se_tmr_req = cmd->se_cmd.se_tmr_req;
- }
+ cmd->tmr_req->se_tmr_req = cmd->se_cmd.se_tmr_req;
cmd->iscsi_opcode = ISCSI_OP_SCSI_TMFUNC;
cmd->i_state = ISTATE_SEND_TASKMGTRSP;
Patches currently in stable-queue which might be from bart.vanassche(a)sandisk.com are
queue-4.4/target-iscsi-fix-iscsi-task-reassignment-handling.patch
This is a note to let you know that I've just added the patch titled
brcmfmac: remove setting IBSS mode when stopping AP
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
brcmfmac-remove-setting-ibss-mode-when-stopping-ap.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9029679f66d976f8c720eb03c4898274803c9923 Mon Sep 17 00:00:00 2001
From: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
Date: Thu, 18 May 2017 17:22:19 +0800
Subject: brcmfmac: remove setting IBSS mode when stopping AP
From: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
commit 9029679f66d976f8c720eb03c4898274803c9923 upstream.
Upon stopping an AP interface the driver disable INFRA mode effectively
setting the interface in IBSS mode. However, this may affect other
interfaces running in INFRA mode. For instance, if user creates and stops
hostap daemon on virtual interface, then association cannot work on
primary interface because default BSS has been set to IBSS mode in
firmware side. The IBSS mode should be set when cfg80211 changes the
interface.
Reviewed-by: Wright Feng <wright.feng(a)cypress.com>
Signed-off-by: Chi-hsien Lin <Chi-Hsien.Lin(a)cypress.com>
[kvalo(a)codeaurora.org: rephased commit log based on discussion]
Signed-off-by: Wright Feng <wright.feng(a)cypress.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Cc: Philipp Rosenberger <p.rosenberger(a)linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 3 ---
1 file changed, 3 deletions(-)
--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -4295,9 +4295,6 @@ static int brcmf_cfg80211_stop_ap(struct
err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_AP, 0);
if (err < 0)
brcmf_err("setting AP mode failed %d\n", err);
- err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_INFRA, 0);
- if (err < 0)
- brcmf_err("setting INFRA mode failed %d\n", err);
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MBSS))
brcmf_fil_iovar_int_set(ifp, "mbss", 0);
err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_REGULATORY,
Patches currently in stable-queue which might be from Chi-Hsien.Lin(a)cypress.com are
queue-4.4/brcmfmac-remove-setting-ibss-mode-when-stopping-ap.patch
This is a note to let you know that I've just added the patch titled
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
security-keys-add-config_keys_compat-to-kconfig.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 47b2c3fff4932e6fc17ce13d51a43c6969714e20 Mon Sep 17 00:00:00 2001
From: Bilal Amarni <bilal.amarni(a)gmail.com>
Date: Thu, 8 Jun 2017 14:47:26 +0100
Subject: security/keys: add CONFIG_KEYS_COMPAT to Kconfig
From: Bilal Amarni <bilal.amarni(a)gmail.com>
commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 upstream.
CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.
At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.
This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.
[DH: Modified to remove arm64 compat enablement also as requested by Eric
Biggers]
Signed-off-by: Bilal Amarni <bilal.amarni(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Cc: James Cowgill <james.cowgill(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/Kconfig | 5 -----
arch/s390/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
arch/x86/Kconfig | 4 ----
security/keys/Kconfig | 4 ++++
5 files changed, 4 insertions(+), 15 deletions(-)
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1082,11 +1082,6 @@ source "arch/powerpc/Kconfig.debug"
source "security/Kconfig"
-config KEYS_COMPAT
- bool
- depends on COMPAT && KEYS
- default y
-
source "crypto/Kconfig"
config PPC_LIB_RHEAP
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -346,9 +346,6 @@ config COMPAT
config SYSVIPC_COMPAT
def_bool y if COMPAT && SYSVIPC
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
config SMP
def_bool y
prompt "Symmetric multi-processing support"
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -549,9 +549,6 @@ config SYSVIPC_COMPAT
depends on COMPAT && SYSVIPC
default y
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
endmenu
source "net/Kconfig"
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2641,10 +2641,6 @@ config COMPAT_FOR_U64_ALIGNMENT
config SYSVIPC_COMPAT
def_bool y
depends on SYSVIPC
-
-config KEYS_COMPAT
- def_bool y
- depends on KEYS
endif
endmenu
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -20,6 +20,10 @@ config KEYS
If you are unsure as to whether this is required, answer N.
+config KEYS_COMPAT
+ def_bool y
+ depends on COMPAT && KEYS
+
config PERSISTENT_KEYRINGS
bool "Enable register of persistent per-UID keyrings"
depends on KEYS
Patches currently in stable-queue which might be from bilal.amarni(a)gmail.com are
queue-4.4/security-keys-add-config_keys_compat-to-kconfig.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: warn user when dma test times out
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 Mon Sep 17 00:00:00 2001
From: Adam Wallis <awallis(a)codeaurora.org>
Date: Thu, 2 Nov 2017 08:53:30 -0400
Subject: dmaengine: dmatest: warn user when dma test times out
From: Adam Wallis <awallis(a)codeaurora.org>
commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks). Ideally, this would be
cleaned up in the thread handler, but at the very least, the kernel
is left in a very precarious scenario that can lead to some long debug
sessions when the crash comes later.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -702,6 +702,7 @@ static int dmatest_func(void *data)
* free it this time?" dancing. For now, just
* leave it dangling.
*/
+ WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
Patches currently in stable-queue which might be from awallis(a)codeaurora.org are
queue-4.14/dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: warn user when dma test times out
to the 4.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
and it can be found in the queue-4.13 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 Mon Sep 17 00:00:00 2001
From: Adam Wallis <awallis(a)codeaurora.org>
Date: Thu, 2 Nov 2017 08:53:30 -0400
Subject: dmaengine: dmatest: warn user when dma test times out
From: Adam Wallis <awallis(a)codeaurora.org>
commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks). Ideally, this would be
cleaned up in the thread handler, but at the very least, the kernel
is left in a very precarious scenario that can lead to some long debug
sessions when the crash comes later.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -696,6 +696,7 @@ static int dmatest_func(void *data)
* free it this time?" dancing. For now, just
* leave it dangling.
*/
+ WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
Patches currently in stable-queue which might be from awallis(a)codeaurora.org are
queue-4.13/dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
This is a note to let you know that I've just added the patch titled
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
security-keys-add-config_keys_compat-to-kconfig.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 47b2c3fff4932e6fc17ce13d51a43c6969714e20 Mon Sep 17 00:00:00 2001
From: Bilal Amarni <bilal.amarni(a)gmail.com>
Date: Thu, 8 Jun 2017 14:47:26 +0100
Subject: security/keys: add CONFIG_KEYS_COMPAT to Kconfig
From: Bilal Amarni <bilal.amarni(a)gmail.com>
commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 upstream.
CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.
At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.
This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.
[DH: Modified to remove arm64 compat enablement also as requested by Eric
Biggers]
Signed-off-by: Bilal Amarni <bilal.amarni(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Cc: James Cowgill <james.cowgill(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/Kconfig | 5 -----
arch/s390/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
arch/x86/Kconfig | 4 ----
security/keys/Kconfig | 4 ++++
5 files changed, 4 insertions(+), 15 deletions(-)
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1070,11 +1070,6 @@ source "arch/powerpc/Kconfig.debug"
source "security/Kconfig"
-config KEYS_COMPAT
- bool
- depends on COMPAT && KEYS
- default y
-
source "crypto/Kconfig"
config PPC_LIB_RHEAP
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -332,9 +332,6 @@ config COMPAT
config SYSVIPC_COMPAT
def_bool y if COMPAT && SYSVIPC
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
config SMP
def_bool y
prompt "Symmetric multi-processing support"
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -542,9 +542,6 @@ config SYSVIPC_COMPAT
depends on COMPAT && SYSVIPC
default y
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
endmenu
source "net/Kconfig"
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2471,10 +2471,6 @@ config COMPAT_FOR_U64_ALIGNMENT
config SYSVIPC_COMPAT
def_bool y
depends on SYSVIPC
-
-config KEYS_COMPAT
- def_bool y
- depends on KEYS
endif
endmenu
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -20,6 +20,10 @@ config KEYS
If you are unsure as to whether this is required, answer N.
+config KEYS_COMPAT
+ def_bool y
+ depends on COMPAT && KEYS
+
config PERSISTENT_KEYRINGS
bool "Enable register of persistent per-UID keyrings"
depends on KEYS
Patches currently in stable-queue which might be from bilal.amarni(a)gmail.com are
queue-3.18/security-keys-add-config_keys_compat-to-kconfig.patch
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Greg-KH,
Here are two target patches for v4.4.y stable, the first of which
did not originally include a stable CC, and the latter did not apply
due to a minor context change.
The series has been cut against v4.4.98. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Nicholas Bellinger (1):
target: Fix node_acl demo-mode + uncached dynamic shutdown regression
drivers/target/iscsi/iscsi_target.c | 19 +++++++------------
drivers/target/target_core_tpg.c | 4 ++--
drivers/target/target_core_transport.c | 4 ++--
include/target/target_core_base.h | 1 +
4 files changed, 12 insertions(+), 16 deletions(-)
--
1.8.5.3
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Greg-KH,
Here are two target patches for v4.9.y stable, the first of which
did not originally include a stable CC, and the latter did not apply
due to a minor context change.
The series has been cut against v4.9.62. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Nicholas Bellinger (1):
qla2xxx: Fix incorrect tcm_qla2xxx_free_cmd use during TMR ABORT (v2)
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 33 ---------------------------------
drivers/target/iscsi/iscsi_target.c | 19 +++++++------------
include/target/target_core_base.h | 1 +
3 files changed, 8 insertions(+), 45 deletions(-)
--
1.8.5.3
Hello,
Upstream commit d01332f1acacc0cb43a61f4244dd2b846d4cd585 ("tipc: fix
link attribute propagation bug") fixes a tipc oops that can be triggered
from user space, we want it also in 4.4-stable. I've backported the
patch, as it does not apply as-is to 4.4.
Richard Alpe (1):
tipc: fix link attribute propagation bug
net/tipc/link.c | 28 ++++++----------------------
net/tipc/link.h | 1 -
2 files changed, 6 insertions(+), 23 deletions(-)
--
2.13.6
Hi,
Is it possible to apply this commit to the stable trees before 4.12?
commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20
Author: Bilal Amarni <bilal.amarni(a)gmail.com>
Date: Thu Jun 8 14:47:26 2017 +0100
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
In commit 20f06ed9f61a ("KEYS: 64-bit MIPS needs to use
compat_sys_keyctl for 32-bit userspace"), the keyctl syscall for 32-bit
MIPS was "fixed" to point at compat_sys_keyctl instead of sys_keyctl.
Unfortunately this caused the syscall to always return ENOSYS because
CONFIG_KEYS_COMPAT was not enabled on MIPS. Instead of fixing this by
manually by enabling KEYS_COMPAT in the MIPS Kconfig, I think applying
the above commit is a better.
Thanks,
James
These two patches get rid of rhashtable the conversion.
First patch is an implicit dependency, rhlist remove interface
is a no-op in case element is not yet in the table, but hlist_del_rcu()
must only be called for conntracks that already have been inserted.
Second patch is the actual revert.
2017-10-30 10:19 GMT+01:00 Daniel Vetter <daniel(a)ffwll.ch>:
> On Tue, Oct 24, 2017 at 11:01:32AM +0200, Benjamin Gaignard wrote:
>> 2017-10-23 17:25 GMT+02:00 Ville Syrjala <ville.syrjala(a)linux.intel.com>:
>> > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
>> >
>> > Since commit 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
>> > even drivers that don't implement accurate vblank timestamps will end
>> > up using drm_crtc_accurate_vblank_count(). That leads to a WARN every
>> > time drm_crtc_arm_vblank_event() gets called. The could be as often
>> > as every frame for each active crtc.
>> >
>> > Considering drm_crtc_accurate_vblank_count() is never any worse than
>> > the drm_vblank_count() we used previously, let's just skip the WARN
>> > unless DRM_UT_VBL is enabled. That way people won't be bothered by
>> > this unless they're debugging vblank code. And let's also change it
>> > to WARN_ONCE() so that even when you're debugging vblank code you
>> > won't get drowned by constant WARNs.
>> >
>> > Cc: stable(a)vger.kernel.org
>> > Cc: Daniel Vetter <daniel(a)ffwll.ch>
>> > Cc: "Szyprowski, Marek" <m.szyprowski(a)samsung.com>
>> > Cc: Andrzej Hajda <a.hajda(a)samsung.com>
>> > Reported-by: Andrzej Hajda <a.hajda(a)samsung.com>
>> > Fixes: 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
>> > Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
>>
>> I have tested it on sti and stm driver, it fix the problem, thanks.
>>
>> Acked-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
>>
>> > ---
>> > drivers/gpu/drm/drm_vblank.c | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
>> > index 13722c373a6a..c81c297995c6 100644
>> > --- a/drivers/gpu/drm/drm_vblank.c
>> > +++ b/drivers/gpu/drm/drm_vblank.c
>> > @@ -299,8 +299,8 @@ u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
>> > u32 vblank;
>> > unsigned long flags;
>> >
>> > - WARN(!dev->driver->get_vblank_timestamp,
>> > - "This function requires support for accurate vblank timestamps.");
>> > + WARN_ONCE(drm_debug & DRM_UT_VBL && !dev->driver->get_vblank_timestamp,
>> > + "This function requires support for accurate vblank timestamps.");
>
> Somewhat a bikeshed, but if we e.g. enable debugging in a CI or piglit
> run, then this could change the results. I'd go with a if ()
> DRM_DEBUG_VBLANK. Either way:
>
> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
>
Does something is missing to merge this fix in drm-misc ?
Without it I got warning at each frame.
Benjamin
>> >
>> > spin_lock_irqsave(&dev->vblank_time_lock, flags);
>> >
>> > --
>> > 2.13.6
>> >
>> > _______________________________________________
>> > dri-devel mailing list
>> > dri-devel(a)lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel(a)lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
This is a note to let you know that I've just added the patch titled
ipv6: flowlabel: do not leave opt->tot_len with garbage
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:49:43 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Sat, 21 Oct 2017 12:26:23 -0700
Subject: ipv6: flowlabel: do not leave opt->tot_len with garbage
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 864e2a1f8aac05effac6063ce316b480facb46ff ]
When syzkaller team brought us a C repro for the crash [1] that
had been reported many times in the past, I finally could find
the root cause.
If FlowLabel info is merged by fl6_merge_options(), we leave
part of the opt_space storage provided by udp/raw/l2tp with random value
in opt_space.tot_len, unless a control message was provided at sendmsg()
time.
Then ip6_setup_cork() would use this random value to perform a kzalloc()
call. Undefined behavior and crashes.
Fix is to properly set tot_len in fl6_merge_options()
At the same time, we can also avoid consuming memory and cpu cycles
to clear it, if every option is copied via a kmemdup(). This is the
change in ip6_setup_cork().
[1]
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 6613 Comm: syz-executor0 Not tainted 4.14.0-rc4+ #127
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801cb64a100 task.stack: ffff8801cc350000
RIP: 0010:ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168
RSP: 0018:ffff8801cc357550 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: ffff8801cc357748 RCX: 0000000000000010
RDX: 0000000000000002 RSI: ffffffff842bd1d9 RDI: 0000000000000014
RBP: ffff8801cc357620 R08: ffff8801cb17f380 R09: ffff8801cc357b10
R10: ffff8801cb64a100 R11: 0000000000000000 R12: ffff8801cc357ab0
R13: ffff8801cc357b10 R14: 0000000000000000 R15: ffff8801c3bbf0c0
FS: 00007f9c5c459700(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020324000 CR3: 00000001d1cf2000 CR4: 00000000001406f0
DR0: 0000000020001010 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Call Trace:
ip6_make_skb+0x282/0x530 net/ipv6/ip6_output.c:1729
udpv6_sendmsg+0x2769/0x3380 net/ipv6/udp.c:1340
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
SYSC_sendto+0x358/0x5a0 net/socket.c:1750
SyS_sendto+0x40/0x50 net/socket.c:1718
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4520a9
RSP: 002b:00007f9c5c458c08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004520a9
RDX: 0000000000000001 RSI: 0000000020fd1000 RDI: 0000000000000016
RBP: 0000000000000086 R08: 0000000020e0afe4 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004bb1ee
R13: 00000000ffffffff R14: 0000000000000016 R15: 0000000000000029
Code: e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 0f 00 00 48 8d 79 04 48 b8 00 00 00 00 00 fc ff df 45 8b 74 24 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RIP: ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168 RSP: ffff8801cc357550
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_output.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -316,6 +316,7 @@ struct ipv6_txoptions *fl6_merge_options
}
opt_space->dst1opt = fopt->dst1opt;
opt_space->opt_flen = fopt->opt_flen;
+ opt_space->tot_len = fopt->tot_len;
return opt_space;
}
EXPORT_SYMBOL_GPL(fl6_merge_options);
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1177,11 +1177,11 @@ int ip6_append_data(struct sock *sk, int
if (WARN_ON(np->cork.opt))
return -EINVAL;
- np->cork.opt = kzalloc(opt->tot_len, sk->sk_allocation);
+ np->cork.opt = kzalloc(sizeof(*opt), sk->sk_allocation);
if (unlikely(np->cork.opt == NULL))
return -ENOBUFS;
- np->cork.opt->tot_len = opt->tot_len;
+ np->cork.opt->tot_len = sizeof(*opt);
np->cork.opt->opt_flen = opt->opt_flen;
np->cork.opt->opt_nflen = opt->opt_nflen;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-3.18/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-3.18/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-3.18/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
ipip: only increase err_count for some certain type icmp in ipip_err
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:49:43 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Thu, 26 Oct 2017 19:19:56 +0800
Subject: ipip: only increase err_count for some certain type icmp in ipip_err
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit f3594f0a7ea36661d7fd942facd7f31a64245f1a ]
t->err_count is used to count the link failure on tunnel and an err
will be reported to user socket in tx path if t->err_count is not 0.
udp socket could even return EHOSTUNREACH to users.
Since commit fd58156e456d ("IPIP: Use ip-tunneling code.") removed
the 'switch check' for icmp type in ipip_err(), err_count would be
increased by the icmp packet with ICMP_EXC_FRAGTIME code. an link
failure would be reported out due to this.
In Jianlin's case, when receiving ICMP_EXC_FRAGTIME a icmp packet,
udp netperf failed with the err:
send_data: data send error: No route to host (errno 113)
We expect this error reported from tunnel to socket when receiving
some certain type icmp, but not ICMP_EXC_FRAGTIME, ICMP_SR_FAILED
or ICMP_PARAMETERPROB ones.
This patch is to bring 'switch check' for icmp type back to ipip_err
so that it only reports link failure for the right type icmp, just as
in ipgre_err() and ipip6_err().
Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ipip.c | 59 +++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 42 insertions(+), 17 deletions(-)
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -128,43 +128,68 @@ static struct rtnl_link_ops ipip_link_op
static int ipip_err(struct sk_buff *skb, u32 info)
{
-
-/* All the routers (except for Linux) return only
- 8 bytes of packet payload. It means, that precise relaying of
- ICMP in the real Internet is absolutely infeasible.
- */
+ /* All the routers (except for Linux) return only
+ 8 bytes of packet payload. It means, that precise relaying of
+ ICMP in the real Internet is absolutely infeasible.
+ */
struct net *net = dev_net(skb->dev);
struct ip_tunnel_net *itn = net_generic(net, ipip_net_id);
const struct iphdr *iph = (const struct iphdr *)skb->data;
- struct ip_tunnel *t;
- int err;
const int type = icmp_hdr(skb)->type;
const int code = icmp_hdr(skb)->code;
+ struct ip_tunnel *t;
+ int err = 0;
+
+ switch (type) {
+ case ICMP_DEST_UNREACH:
+ switch (code) {
+ case ICMP_SR_FAILED:
+ /* Impossible event. */
+ goto out;
+ default:
+ /* All others are translated to HOST_UNREACH.
+ * rfc2003 contains "deep thoughts" about NET_UNREACH,
+ * I believe they are just ether pollution. --ANK
+ */
+ break;
+ }
+ break;
+
+ case ICMP_TIME_EXCEEDED:
+ if (code != ICMP_EXC_TTL)
+ goto out;
+ break;
+
+ case ICMP_REDIRECT:
+ break;
+
+ default:
+ goto out;
+ }
- err = -ENOENT;
t = ip_tunnel_lookup(itn, skb->dev->ifindex, TUNNEL_NO_KEY,
iph->daddr, iph->saddr, 0);
- if (t == NULL)
+ if (!t) {
+ err = -ENOENT;
goto out;
+ }
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
- ipv4_update_pmtu(skb, dev_net(skb->dev), info,
- t->parms.link, 0, IPPROTO_IPIP, 0);
- err = 0;
+ ipv4_update_pmtu(skb, net, info, t->parms.link, 0,
+ iph->protocol, 0);
goto out;
}
if (type == ICMP_REDIRECT) {
- ipv4_redirect(skb, dev_net(skb->dev), t->parms.link, 0,
- IPPROTO_IPIP, 0);
- err = 0;
+ ipv4_redirect(skb, net, t->parms.link, 0, iph->protocol, 0);
goto out;
}
- if (t->parms.iph.daddr == 0)
+ if (t->parms.iph.daddr == 0) {
+ err = -ENOENT;
goto out;
+ }
- err = 0;
if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED)
goto out;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-3.18/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-3.18/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
This is a note to let you know that I've just added the patch titled
ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:49:43 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Thu, 26 Oct 2017 19:23:27 +0800
Subject: ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit f8d20b46ce55cf40afb30dcef6d9288f7ef46d9b ]
The similar fix in patch 'ipip: only increase err_count for some
certain type icmp in ipip_err' is needed for ip6gre_err.
In Jianlin's case, udp netperf broke even when receiving a TooBig
icmpv6 packet.
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_gre.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -409,13 +409,16 @@ static void ip6gre_err(struct sk_buff *s
case ICMPV6_DEST_UNREACH:
net_warn_ratelimited("%s: Path to destination invalid or inactive!\n",
t->parms.name);
- break;
+ if (code != ICMPV6_PORT_UNREACH)
+ break;
+ return;
case ICMPV6_TIME_EXCEED:
if (code == ICMPV6_EXC_HOPLIMIT) {
net_warn_ratelimited("%s: Too small hop limit or routing loop in tunnel!\n",
t->parms.name);
+ break;
}
- break;
+ return;
case ICMPV6_PARAMPROB:
teli = 0;
if (code == ICMPV6_HDR_FIELD)
@@ -431,13 +434,13 @@ static void ip6gre_err(struct sk_buff *s
net_warn_ratelimited("%s: Recipient unable to parse tunneled packet!\n",
t->parms.name);
}
- break;
+ return;
case ICMPV6_PKT_TOOBIG:
mtu = be32_to_cpu(info) - offset;
if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
t->dev->mtu = mtu;
- break;
+ return;
}
if (time_before(jiffies, t->err_time + IP6TUNNEL_ERR_TIMEO))
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-3.18/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-3.18/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
This is a note to let you know that I've just added the patch titled
tun/tap: sanitize TUNSETSNDBUF input
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tun-tap-sanitize-tunsetsndbuf-input.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Craig Gallek <kraig(a)google.com>
Date: Mon, 30 Oct 2017 18:50:11 -0400
Subject: tun/tap: sanitize TUNSETSNDBUF input
From: Craig Gallek <kraig(a)google.com>
[ Upstream commit 93161922c658c714715686cd0cf69b090cb9bf1d ]
Syzkaller found several variants of the lockup below by setting negative
values with the TUNSETSNDBUF ioctl. This patch adds a sanity check
to both the tun and tap versions of this ioctl.
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389]
Modules linked in:
irq event stamp: 329692056
hardirqs last enabled at (329692055): [<ffffffff824b8381>] _raw_spin_unlock_irqrestore+0x31/0x75
hardirqs last disabled at (329692056): [<ffffffff824b9e58>] apic_timer_interrupt+0x98/0xb0
softirqs last enabled at (35659740): [<ffffffff824bc958>] __do_softirq+0x328/0x48c
softirqs last disabled at (35659731): [<ffffffff811c796c>] irq_exit+0xbc/0xd0
CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880009452140 task.stack: ffff880006a20000
RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80
RSP: 0018:ffff880006a27c50 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10
RAX: ffff880009ac68d0 RBX: ffff880006a27ce0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff880006a27ce0 RDI: ffff880009ac6900
RBP: ffff880006a27c60 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 000000000063ff00 R12: ffff880009ac6900
R13: ffff880006a27cf8 R14: 0000000000000001 R15: ffff880006a27cf8
FS: 00007f4be4838700(0000) GS:ffff88000cc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020101000 CR3: 0000000009616000 CR4: 00000000000006f0
Call Trace:
prepare_to_wait+0x26/0xc0
sock_alloc_send_pskb+0x14e/0x270
? remove_wait_queue+0x60/0x60
tun_get_user+0x2cc/0x19d0
? __tun_get+0x60/0x1b0
tun_chr_write_iter+0x57/0x86
__vfs_write+0x156/0x1e0
vfs_write+0xf7/0x230
SyS_write+0x57/0xd0
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x7f4be4356df9
RSP: 002b:00007ffc18101c08 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4be4356df9
RDX: 0000000000000046 RSI: 0000000020101000 RDI: 0000000000000005
RBP: 00007ffc18101c40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000293 R12: 0000559c75f64780
R13: 00007ffc18101d30 R14: 0000000000000000 R15: 0000000000000000
Fixes: 33dccbb050bb ("tun: Limit amount of queued packets per device")
Fixes: 20d29d7a916a ("net: macvtap driver")
Signed-off-by: Craig Gallek <kraig(a)google.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/macvtap.c | 2 ++
drivers/net/tun.c | 4 ++++
2 files changed, 6 insertions(+)
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -1047,6 +1047,8 @@ static long macvtap_ioctl(struct file *f
case TUNSETSNDBUF:
if (get_user(u, up))
return -EFAULT;
+ if (s <= 0)
+ return -EINVAL;
q->sk.sk_sndbuf = u;
return 0;
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2054,6 +2054,10 @@ static long __tun_chr_ioctl(struct file
ret = -EFAULT;
break;
}
+ if (sndbuf <= 0) {
+ ret = -EINVAL;
+ break;
+ }
tun->sndbuf = sndbuf;
tun_set_sndbuf(tun);
Patches currently in stable-queue which might be from kraig(a)google.com are
queue-3.18/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
tun: call dev_get_valid_name() before register_netdevice()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tun-call-dev_get_valid_name-before-register_netdevice.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Fri, 13 Oct 2017 11:58:53 -0700
Subject: tun: call dev_get_valid_name() before register_netdevice()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
[ Upstream commit 0ad646c81b2182f7fa67ec0c8c825e0ee165696d ]
register_netdevice() could fail early when we have an invalid
dev name, in which case ->ndo_uninit() is not called. For tun
device, this is a problem because a timer etc. are already
initialized and it expects ->ndo_uninit() to clean them up.
We could move these initializations into a ->ndo_init() so
that register_netdevice() knows better, however this is still
complicated due to the logic in tun_detach().
Therefore, I choose to just call dev_get_valid_name() before
register_netdevice(), which is quicker and much easier to audit.
And for this specific case, it is already enough.
Fixes: 96442e42429e ("tuntap: choose the txq based on rxq")
Reported-by: Dmitry Alexeev <avekceeb(a)gmail.com>
Cc: Jason Wang <jasowang(a)redhat.com>
Cc: "Michael S. Tsirkin" <mst(a)redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/tun.c | 3 +++
include/linux/netdevice.h | 3 +++
net/core/dev.c | 6 +++---
3 files changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1656,6 +1656,9 @@ static int tun_set_iff(struct net *net,
if (!dev)
return -ENOMEM;
+ err = dev_get_valid_name(net, dev, name);
+ if (err)
+ goto err_free_dev;
dev_net_set(dev, net);
dev->rtnl_link_ops = &tun_link_ops;
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3245,6 +3245,9 @@ struct net_device *alloc_netdev_mqs(int
unsigned char name_assign_type,
void (*setup)(struct net_device *),
unsigned int txqs, unsigned int rxqs);
+int dev_get_valid_name(struct net *net, struct net_device *dev,
+ const char *name);
+
#define alloc_netdev(sizeof_priv, name, name_assign_type, setup) \
alloc_netdev_mqs(sizeof_priv, name, name_assign_type, setup, 1, 1)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1059,9 +1059,8 @@ static int dev_alloc_name_ns(struct net
return ret;
}
-static int dev_get_valid_name(struct net *net,
- struct net_device *dev,
- const char *name)
+int dev_get_valid_name(struct net *net, struct net_device *dev,
+ const char *name)
{
BUG_ON(!net);
@@ -1077,6 +1076,7 @@ static int dev_get_valid_name(struct net
return 0;
}
+EXPORT_SYMBOL(dev_get_valid_name);
/**
* dev_change_name - change name of a device
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-3.18/tun-call-dev_get_valid_name-before-register_netdevice.patch
queue-3.18/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
This is a note to let you know that I've just added the patch titled
tun: allow positive return values on dev_get_valid_name() call
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Julien Gomes <julien(a)arista.com>
Date: Wed, 25 Oct 2017 11:50:50 -0700
Subject: tun: allow positive return values on dev_get_valid_name() call
From: Julien Gomes <julien(a)arista.com>
[ Upstream commit 5c25f65fd1e42685f7ccd80e0621829c105785d9 ]
If the name argument of dev_get_valid_name() contains "%d", it will try
to assign it a unit number in __dev__alloc_name() and return either the
unit number (>= 0) or an error code (< 0).
Considering positive values as error values prevent tun device creations
relying this mechanism, therefor we should only consider negative values
as errors here.
Signed-off-by: Julien Gomes <julien(a)arista.com>
Acked-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/tun.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1657,7 +1657,7 @@ static int tun_set_iff(struct net *net,
if (!dev)
return -ENOMEM;
err = dev_get_valid_name(net, dev, name);
- if (err)
+ if (err < 0)
goto err_free_dev;
dev_net_set(dev, net);
Patches currently in stable-queue which might be from julien(a)arista.com are
queue-3.18/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
This is a note to let you know that I've just added the patch titled
tcp: fix tcp_mtu_probe() vs highest_sack
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Mon, 30 Oct 2017 23:08:20 -0700
Subject: tcp: fix tcp_mtu_probe() vs highest_sack
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 2b7cda9c35d3b940eb9ce74b30bbd5eb30db493d ]
Based on SNMP values provided by Roman, Yuchung made the observation
that some crashes in tcp_sacktag_walk() might be caused by MTU probing.
Looking at tcp_mtu_probe(), I found that when a new skb was placed
in front of the write queue, we were not updating tcp highest sack.
If one skb is freed because all its content was copied to the new skb
(for MTU probing), then tp->highest_sack could point to a now freed skb.
Bad things would then happen, including infinite loops.
This patch renames tcp_highest_sack_combine() and uses it
from tcp_mtu_probe() to fix the bug.
Note that I also removed one test against tp->sacked_out,
since we want to replace tp->highest_sack regardless of whatever
condition, since keeping a stale pointer to freed skb is a recipe
for disaster.
Fixes: a47e5a988a57 ("[TCP]: Convert highest_sack to sk_buff to allow direct access")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Alexei Starovoitov <alexei.starovoitov(a)gmail.com>
Reported-by: Roman Gushchin <guro(a)fb.com>
Reported-by: Oleksandr Natalenko <oleksandr(a)natalenko.name>
Acked-by: Alexei Starovoitov <ast(a)kernel.org>
Acked-by: Neal Cardwell <ncardwell(a)google.com>
Acked-by: Yuchung Cheng <ycheng(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/tcp.h | 6 +++---
net/ipv4/tcp_output.c | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1532,12 +1532,12 @@ static inline void tcp_highest_sack_rese
tcp_sk(sk)->highest_sack = tcp_write_queue_head(sk);
}
-/* Called when old skb is about to be deleted (to be combined with new skb) */
-static inline void tcp_highest_sack_combine(struct sock *sk,
+/* Called when old skb is about to be deleted and replaced by new skb */
+static inline void tcp_highest_sack_replace(struct sock *sk,
struct sk_buff *old,
struct sk_buff *new)
{
- if (tcp_sk(sk)->sacked_out && (old == tcp_sk(sk)->highest_sack))
+ if (old == tcp_highest_sack(sk))
tcp_sk(sk)->highest_sack = new;
}
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1870,6 +1870,7 @@ static int tcp_mtu_probe(struct sock *sk
nskb->ip_summed = skb->ip_summed;
tcp_insert_write_queue_before(nskb, skb, sk);
+ tcp_highest_sack_replace(sk, skb, nskb);
len = 0;
tcp_for_write_queue_from_safe(skb, next, sk) {
@@ -2374,7 +2375,7 @@ static void tcp_collapse_retrans(struct
BUG_ON(tcp_skb_pcount(skb) != 1 || tcp_skb_pcount(next_skb) != 1);
- tcp_highest_sack_combine(sk, next_skb, skb);
+ tcp_highest_sack_replace(sk, next_skb, skb);
tcp_unlink_write_queue(next_skb, sk);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-3.18/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-3.18/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
sctp: reset owner sk for data chunks on out queues when migrating a sock
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Sat, 28 Oct 2017 02:13:29 +0800
Subject: sctp: reset owner sk for data chunks on out queues when migrating a sock
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit d04adf1b355181e737b6b1e23d801b07f0b7c4c0 ]
Now when migrating sock to another one in sctp_sock_migrate(), it only
resets owner sk for the data in receive queues, not the chunks on out
queues.
It would cause that data chunks length on the sock is not consistent
with sk sk_wmem_alloc. When closing the sock or freeing these chunks,
the old sk would never be freed, and the new sock may crash due to
the overflow sk_wmem_alloc.
syzbot found this issue with this series:
r0 = socket$inet_sctp()
sendto$inet(r0)
listen(r0)
accept4(r0)
close(r0)
Although listen() should have returned error when one TCP-style socket
is in connecting (I may fix this one in another patch), it could also
be reproduced by peeling off an assoc.
This issue is there since very beginning.
This patch is to reset owner sk for the chunks on out queues so that
sk sk_wmem_alloc has correct value after accept one sock or peeloff
an assoc to one sock.
Note that when resetting owner sk for chunks on outqueue, it has to
sctp_clear_owner_w/skb_orphan chunks before changing assoc->base.sk
first and then sctp_set_owner_w them after changing assoc->base.sk,
due to that sctp_wfree and it's callees are using assoc->base.sk.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -173,6 +173,36 @@ static inline void sctp_set_owner_w(stru
sk_mem_charge(sk, chunk->skb->truesize);
}
+static void sctp_clear_owner_w(struct sctp_chunk *chunk)
+{
+ skb_orphan(chunk->skb);
+}
+
+static void sctp_for_each_tx_datachunk(struct sctp_association *asoc,
+ void (*cb)(struct sctp_chunk *))
+
+{
+ struct sctp_outq *q = &asoc->outqueue;
+ struct sctp_transport *t;
+ struct sctp_chunk *chunk;
+
+ list_for_each_entry(t, &asoc->peer.transport_addr_list, transports)
+ list_for_each_entry(chunk, &t->transmitted, transmitted_list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->retransmit, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->sacked, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->abandoned, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->out_chunk_list, list)
+ cb(chunk);
+}
+
/* Verify that this is a valid address. */
static inline int sctp_verify_addr(struct sock *sk, union sctp_addr *addr,
int len)
@@ -7367,7 +7397,9 @@ static void sctp_sock_migrate(struct soc
* paths won't try to lock it and then oldsk.
*/
lock_sock_nested(newsk, SINGLE_DEPTH_NESTING);
+ sctp_for_each_tx_datachunk(assoc, sctp_clear_owner_w);
sctp_assoc_migrate(assoc, newsk);
+ sctp_for_each_tx_datachunk(assoc, sctp_set_owner_w);
/* If the association on the newsk is already closed before accept()
* is called, set RCV_SHUTDOWN flag.
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
This is a note to let you know that I've just added the patch titled
sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Wed, 18 Oct 2017 21:37:49 +0800
Subject: sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 1cc276cec9ec574d41cf47dfc0f51406b6f26ab4 ]
Now sctp processes icmp redirect packet in sctp_icmp_redirect where
it calls sctp_transport_dst_check in which tp->dst can be released.
The problem is before calling sctp_transport_dst_check, it doesn't
check sock_owned_by_user, which means tp->dst could be freed while
a process is accessing it with owning the socket.
An use-after-free issue could be triggered by this.
This patch is to fix it by checking sock_owned_by_user before calling
sctp_transport_dst_check in sctp_icmp_redirect, so that it would not
release tp->dst if users still hold sock lock.
Besides, the same issue fixed in commit 45caeaa5ac0b ("dccp/tcp: fix
routing redirect race") on sctp also needs this check.
Fixes: 55be7a9c6074 ("ipv4: Add redirect support to all protocol icmp error handlers")
Reported-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -420,7 +420,7 @@ void sctp_icmp_redirect(struct sock *sk,
{
struct dst_entry *dst;
- if (!t)
+ if (sock_owned_by_user(sk) || !t)
return;
dst = sctp_transport_dst_check(t);
if (dst)
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
This is a note to let you know that I've just added the patch titled
net/unix: don't show information about sockets from other namespaces
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Andrei Vagin <avagin(a)openvz.org>
Date: Wed, 25 Oct 2017 10:16:42 -0700
Subject: net/unix: don't show information about sockets from other namespaces
From: Andrei Vagin <avagin(a)openvz.org>
[ Upstream commit 0f5da659d8f1810f44de14acf2c80cd6499623a0 ]
socket_diag shows information only about sockets from a namespace where
a diag socket lives.
But if we request information about one unix socket, the kernel don't
check that its netns is matched with a diag socket namespace, so any
user can get information about any unix socket in a system. This looks
like a bug.
v2: add a Fixes tag
Fixes: 51d7cccf0723 ("net: make sock diag per-namespace")
Signed-off-by: Andrei Vagin <avagin(a)openvz.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/unix/diag.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -256,6 +256,8 @@ static int unix_diag_get_exact(struct sk
err = -ENOENT;
if (sk == NULL)
goto out_nosk;
+ if (!net_eq(sock_net(sk), net))
+ goto out;
err = sock_diag_check_cookie(sk, req->udiag_cookie);
if (err)
Patches currently in stable-queue which might be from avagin(a)openvz.org are
queue-3.18/net-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
This is a note to let you know that I've just added the patch titled
l2tp: check ps->sock before running pppol2tp_session_ioctl()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Guillaume Nault <g.nault(a)alphalink.fr>
Date: Fri, 13 Oct 2017 19:22:35 +0200
Subject: l2tp: check ps->sock before running pppol2tp_session_ioctl()
From: Guillaume Nault <g.nault(a)alphalink.fr>
[ Upstream commit 5903f594935a3841137c86b9d5b75143a5b7121c ]
When pppol2tp_session_ioctl() is called by pppol2tp_tunnel_ioctl(),
the session may be unconnected. That is, it was created by
pppol2tp_session_create() and hasn't been connected with
pppol2tp_connect(). In this case, ps->sock is NULL, so we need to check
for this case in order to avoid dereferencing a NULL pointer.
Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_ppp.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -1017,6 +1017,9 @@ static int pppol2tp_session_ioctl(struct
session->name, cmd, arg);
sk = ps->sock;
+ if (!sk)
+ return -EBADR;
+
sock_hold(sk);
switch (cmd) {
Patches currently in stable-queue which might be from g.nault(a)alphalink.fr are
queue-3.18/l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
This is a note to let you know that I've just added the patch titled
tcp/dccp: fix other lockdep splats accessing ireq_opt
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Tue, 24 Oct 2017 08:20:31 -0700
Subject: tcp/dccp: fix other lockdep splats accessing ireq_opt
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 06f877d613be3621604c2520ec0351d9fbdca15f ]
In my first attempt to fix the lockdep splat, I forgot we could
enter inet_csk_route_req() with a freshly allocated request socket,
for which refcount has not yet been elevated, due to complex
SLAB_TYPESAFE_BY_RCU rules.
We either are in rcu_read_lock() section _or_ we own a refcount on the
request.
Correct RCU verb to use here is rcu_dereference_check(), although it is
not possible to prove we actually own a reference on a shared
refcount :/
In v2, I added ireq_opt_deref() helper and use in three places, to fix other
possible splats.
[ 49.844590] lockdep_rcu_suspicious+0xea/0xf3
[ 49.846487] inet_csk_route_req+0x53/0x14d
[ 49.848334] tcp_v4_route_req+0xe/0x10
[ 49.850174] tcp_conn_request+0x31c/0x6a0
[ 49.851992] ? __lock_acquire+0x614/0x822
[ 49.854015] tcp_v4_conn_request+0x5a/0x79
[ 49.855957] ? tcp_v4_conn_request+0x5a/0x79
[ 49.858052] tcp_rcv_state_process+0x98/0xdcc
[ 49.859990] ? sk_filter_trim_cap+0x2f6/0x307
[ 49.862085] tcp_v4_do_rcv+0xfc/0x145
[ 49.864055] ? tcp_v4_do_rcv+0xfc/0x145
[ 49.866173] tcp_v4_rcv+0x5ab/0xaf9
[ 49.868029] ip_local_deliver_finish+0x1af/0x2e7
[ 49.870064] ip_local_deliver+0x1b2/0x1c5
[ 49.871775] ? inet_del_offload+0x45/0x45
[ 49.873916] ip_rcv_finish+0x3f7/0x471
[ 49.875476] ip_rcv+0x3f1/0x42f
[ 49.876991] ? ip_local_deliver_finish+0x2e7/0x2e7
[ 49.878791] __netif_receive_skb_core+0x6d3/0x950
[ 49.880701] ? process_backlog+0x7e/0x216
[ 49.882589] __netif_receive_skb+0x1d/0x5e
[ 49.884122] process_backlog+0x10c/0x216
[ 49.885812] net_rx_action+0x147/0x3df
Fixes: a6ca7abe53633 ("tcp/dccp: fix lockdep splat in inet_csk_route_req()")
Fixes: c92e8c02fe66 ("tcp/dccp: fix ireq->opt races")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: kernel test robot <fengguang.wu(a)intel.com>
Reported-by: Maciej Żenczykowski <maze(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/inet_sock.h | 6 ++++++
net/dccp/ipv4.c | 2 +-
net/ipv4/inet_connection_sock.c | 4 ++--
net/ipv4/tcp_ipv4.c | 2 +-
4 files changed, 10 insertions(+), 4 deletions(-)
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -113,6 +113,12 @@ static inline u32 inet_request_mark(cons
return sk->sk_mark;
}
+static inline struct ip_options_rcu *ireq_opt_deref(const struct inet_request_sock *ireq)
+{
+ return rcu_dereference_check(ireq->ireq_opt,
+ atomic_read(&ireq->req.rsk_refcnt) > 0);
+}
+
struct inet_cork {
unsigned int flags;
__be32 addr;
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -495,7 +495,7 @@ static int dccp_v4_send_response(const s
ireq->ir_rmt_addr);
err = ip_build_and_send_pkt(skb, sk, ireq->ir_loc_addr,
ireq->ir_rmt_addr,
- rcu_dereference(ireq->ireq_opt));
+ ireq_opt_deref(ireq));
err = net_xmit_eval(err);
}
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -415,8 +415,8 @@ struct dst_entry *inet_csk_route_req(con
struct ip_options_rcu *opt;
struct rtable *rt;
- opt = rcu_dereference_protected(ireq->ireq_opt,
- atomic_read(&req->rsk_refcnt) > 0);
+ opt = ireq_opt_deref(ireq);
+
flowi4_init_output(fl4, ireq->ir_iif, ireq->ir_mark,
RT_CONN_FLAGS(sk), RT_SCOPE_UNIVERSE,
sk->sk_protocol, inet_sk_flowi_flags(sk),
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -856,7 +856,7 @@ static int tcp_v4_send_synack(const stru
err = ip_build_and_send_pkt(skb, sk, ireq->ir_loc_addr,
ireq->ir_rmt_addr,
- rcu_dereference(ireq->ireq_opt));
+ ireq_opt_deref(ireq));
err = net_xmit_eval(err);
}
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/tcp-dccp-fix-ireq-opt-races.patch
queue-4.4/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.4/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.4/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.4/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.4/tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
This is a note to let you know that I've just added the patch titled
tcp/dccp: fix lockdep splat in inet_csk_route_req()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Sun, 22 Oct 2017 12:33:57 -0700
Subject: tcp/dccp: fix lockdep splat in inet_csk_route_req()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit a6ca7abe53633d08eea1c6756cb49c9b2d4c90bf ]
This patch fixes the following lockdep splat in inet_csk_route_req()
lockdep_rcu_suspicious
inet_csk_route_req
tcp_v4_send_synack
tcp_rtx_synack
inet_rtx_syn_ack
tcp_fastopen_synack_time
tcp_retransmit_timer
tcp_write_timer_handler
tcp_write_timer
call_timer_fn
Thread running inet_csk_route_req() owns a reference on the request
socket, so we have the guarantee ireq->ireq_opt wont be changed or
freed.
lockdep can enforce this invariant for us.
Fixes: c92e8c02fe66 ("tcp/dccp: fix ireq->opt races")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/inet_connection_sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -415,7 +415,8 @@ struct dst_entry *inet_csk_route_req(con
struct ip_options_rcu *opt;
struct rtable *rt;
- opt = rcu_dereference(ireq->ireq_opt);
+ opt = rcu_dereference_protected(ireq->ireq_opt,
+ atomic_read(&req->rsk_refcnt) > 0);
flowi4_init_output(fl4, ireq->ir_iif, ireq->ir_mark,
RT_CONN_FLAGS(sk), RT_SCOPE_UNIVERSE,
sk->sk_protocol, inet_sk_flowi_flags(sk),
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/tcp-dccp-fix-ireq-opt-races.patch
queue-4.4/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.4/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.4/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.4/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.4/tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
This is a note to let you know that I've just added the patch titled
ipip: only increase err_count for some certain type icmp in ipip_err
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Thu, 26 Oct 2017 19:19:56 +0800
Subject: ipip: only increase err_count for some certain type icmp in ipip_err
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit f3594f0a7ea36661d7fd942facd7f31a64245f1a ]
t->err_count is used to count the link failure on tunnel and an err
will be reported to user socket in tx path if t->err_count is not 0.
udp socket could even return EHOSTUNREACH to users.
Since commit fd58156e456d ("IPIP: Use ip-tunneling code.") removed
the 'switch check' for icmp type in ipip_err(), err_count would be
increased by the icmp packet with ICMP_EXC_FRAGTIME code. an link
failure would be reported out due to this.
In Jianlin's case, when receiving ICMP_EXC_FRAGTIME a icmp packet,
udp netperf failed with the err:
send_data: data send error: No route to host (errno 113)
We expect this error reported from tunnel to socket when receiving
some certain type icmp, but not ICMP_EXC_FRAGTIME, ICMP_SR_FAILED
or ICMP_PARAMETERPROB ones.
This patch is to bring 'switch check' for icmp type back to ipip_err
so that it only reports link failure for the right type icmp, just as
in ipgre_err() and ipip6_err().
Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ipip.c | 58 ++++++++++++++++++++++++++++++++++++++++----------------
1 file changed, 42 insertions(+), 16 deletions(-)
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -129,42 +129,68 @@ static struct rtnl_link_ops ipip_link_op
static int ipip_err(struct sk_buff *skb, u32 info)
{
-/* All the routers (except for Linux) return only
- 8 bytes of packet payload. It means, that precise relaying of
- ICMP in the real Internet is absolutely infeasible.
- */
+ /* All the routers (except for Linux) return only
+ 8 bytes of packet payload. It means, that precise relaying of
+ ICMP in the real Internet is absolutely infeasible.
+ */
struct net *net = dev_net(skb->dev);
struct ip_tunnel_net *itn = net_generic(net, ipip_net_id);
const struct iphdr *iph = (const struct iphdr *)skb->data;
- struct ip_tunnel *t;
- int err;
const int type = icmp_hdr(skb)->type;
const int code = icmp_hdr(skb)->code;
+ struct ip_tunnel *t;
+ int err = 0;
+
+ switch (type) {
+ case ICMP_DEST_UNREACH:
+ switch (code) {
+ case ICMP_SR_FAILED:
+ /* Impossible event. */
+ goto out;
+ default:
+ /* All others are translated to HOST_UNREACH.
+ * rfc2003 contains "deep thoughts" about NET_UNREACH,
+ * I believe they are just ether pollution. --ANK
+ */
+ break;
+ }
+ break;
+
+ case ICMP_TIME_EXCEEDED:
+ if (code != ICMP_EXC_TTL)
+ goto out;
+ break;
+
+ case ICMP_REDIRECT:
+ break;
+
+ default:
+ goto out;
+ }
- err = -ENOENT;
t = ip_tunnel_lookup(itn, skb->dev->ifindex, TUNNEL_NO_KEY,
iph->daddr, iph->saddr, 0);
- if (!t)
+ if (!t) {
+ err = -ENOENT;
goto out;
+ }
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
- ipv4_update_pmtu(skb, dev_net(skb->dev), info,
- t->parms.link, 0, IPPROTO_IPIP, 0);
- err = 0;
+ ipv4_update_pmtu(skb, net, info, t->parms.link, 0,
+ iph->protocol, 0);
goto out;
}
if (type == ICMP_REDIRECT) {
- ipv4_redirect(skb, dev_net(skb->dev), t->parms.link, 0,
- IPPROTO_IPIP, 0);
- err = 0;
+ ipv4_redirect(skb, net, t->parms.link, 0, iph->protocol, 0);
goto out;
}
- if (t->parms.iph.daddr == 0)
+ if (t->parms.iph.daddr == 0) {
+ err = -ENOENT;
goto out;
+ }
- err = 0;
if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED)
goto out;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.4/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.4/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
This is a note to let you know that I've just added the patch titled
tun/tap: sanitize TUNSETSNDBUF input
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tun-tap-sanitize-tunsetsndbuf-input.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Craig Gallek <kraig(a)google.com>
Date: Mon, 30 Oct 2017 18:50:11 -0400
Subject: tun/tap: sanitize TUNSETSNDBUF input
From: Craig Gallek <kraig(a)google.com>
[ Upstream commit 93161922c658c714715686cd0cf69b090cb9bf1d ]
Syzkaller found several variants of the lockup below by setting negative
values with the TUNSETSNDBUF ioctl. This patch adds a sanity check
to both the tun and tap versions of this ioctl.
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389]
Modules linked in:
irq event stamp: 329692056
hardirqs last enabled at (329692055): [<ffffffff824b8381>] _raw_spin_unlock_irqrestore+0x31/0x75
hardirqs last disabled at (329692056): [<ffffffff824b9e58>] apic_timer_interrupt+0x98/0xb0
softirqs last enabled at (35659740): [<ffffffff824bc958>] __do_softirq+0x328/0x48c
softirqs last disabled at (35659731): [<ffffffff811c796c>] irq_exit+0xbc/0xd0
CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880009452140 task.stack: ffff880006a20000
RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80
RSP: 0018:ffff880006a27c50 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10
RAX: ffff880009ac68d0 RBX: ffff880006a27ce0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff880006a27ce0 RDI: ffff880009ac6900
RBP: ffff880006a27c60 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 000000000063ff00 R12: ffff880009ac6900
R13: ffff880006a27cf8 R14: 0000000000000001 R15: ffff880006a27cf8
FS: 00007f4be4838700(0000) GS:ffff88000cc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020101000 CR3: 0000000009616000 CR4: 00000000000006f0
Call Trace:
prepare_to_wait+0x26/0xc0
sock_alloc_send_pskb+0x14e/0x270
? remove_wait_queue+0x60/0x60
tun_get_user+0x2cc/0x19d0
? __tun_get+0x60/0x1b0
tun_chr_write_iter+0x57/0x86
__vfs_write+0x156/0x1e0
vfs_write+0xf7/0x230
SyS_write+0x57/0xd0
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x7f4be4356df9
RSP: 002b:00007ffc18101c08 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4be4356df9
RDX: 0000000000000046 RSI: 0000000020101000 RDI: 0000000000000005
RBP: 00007ffc18101c40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000293 R12: 0000559c75f64780
R13: 00007ffc18101d30 R14: 0000000000000000 R15: 0000000000000000
Fixes: 33dccbb050bb ("tun: Limit amount of queued packets per device")
Fixes: 20d29d7a916a ("net: macvtap driver")
Signed-off-by: Craig Gallek <kraig(a)google.com>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/macvtap.c | 2 ++
drivers/net/tun.c | 4 ++++
2 files changed, 6 insertions(+)
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -1117,6 +1117,8 @@ static long macvtap_ioctl(struct file *f
case TUNSETSNDBUF:
if (get_user(s, sp))
return -EFAULT;
+ if (s <= 0)
+ return -EINVAL;
q->sk.sk_sndbuf = s;
return 0;
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2065,6 +2065,10 @@ static long __tun_chr_ioctl(struct file
ret = -EFAULT;
break;
}
+ if (sndbuf <= 0) {
+ ret = -EINVAL;
+ break;
+ }
tun->sndbuf = sndbuf;
tun_set_sndbuf(tun);
Patches currently in stable-queue which might be from kraig(a)google.com are
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
tun: call dev_get_valid_name() before register_netdevice()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tun-call-dev_get_valid_name-before-register_netdevice.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Fri, 13 Oct 2017 11:58:53 -0700
Subject: tun: call dev_get_valid_name() before register_netdevice()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
[ Upstream commit 0ad646c81b2182f7fa67ec0c8c825e0ee165696d ]
register_netdevice() could fail early when we have an invalid
dev name, in which case ->ndo_uninit() is not called. For tun
device, this is a problem because a timer etc. are already
initialized and it expects ->ndo_uninit() to clean them up.
We could move these initializations into a ->ndo_init() so
that register_netdevice() knows better, however this is still
complicated due to the logic in tun_detach().
Therefore, I choose to just call dev_get_valid_name() before
register_netdevice(), which is quicker and much easier to audit.
And for this specific case, it is already enough.
Fixes: 96442e42429e ("tuntap: choose the txq based on rxq")
Reported-by: Dmitry Alexeev <avekceeb(a)gmail.com>
Cc: Jason Wang <jasowang(a)redhat.com>
Cc: "Michael S. Tsirkin" <mst(a)redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/tun.c | 3 +++
include/linux/netdevice.h | 3 +++
net/core/dev.c | 6 +++---
3 files changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1684,6 +1684,9 @@ static int tun_set_iff(struct net *net,
if (!dev)
return -ENOMEM;
+ err = dev_get_valid_name(net, dev, name);
+ if (err)
+ goto err_free_dev;
dev_net_set(dev, net);
dev->rtnl_link_ops = &tun_link_ops;
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3469,6 +3469,9 @@ struct net_device *alloc_netdev_mqs(int
unsigned char name_assign_type,
void (*setup)(struct net_device *),
unsigned int txqs, unsigned int rxqs);
+int dev_get_valid_name(struct net *net, struct net_device *dev,
+ const char *name);
+
#define alloc_netdev(sizeof_priv, name, name_assign_type, setup) \
alloc_netdev_mqs(sizeof_priv, name, name_assign_type, setup, 1, 1)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1111,9 +1111,8 @@ static int dev_alloc_name_ns(struct net
return ret;
}
-static int dev_get_valid_name(struct net *net,
- struct net_device *dev,
- const char *name)
+int dev_get_valid_name(struct net *net, struct net_device *dev,
+ const char *name)
{
BUG_ON(!net);
@@ -1129,6 +1128,7 @@ static int dev_get_valid_name(struct net
return 0;
}
+EXPORT_SYMBOL(dev_get_valid_name);
/**
* dev_change_name - change name of a device
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.4/tun-call-dev_get_valid_name-before-register_netdevice.patch
queue-4.4/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
This is a note to let you know that I've just added the patch titled
tun: allow positive return values on dev_get_valid_name() call
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Julien Gomes <julien(a)arista.com>
Date: Wed, 25 Oct 2017 11:50:50 -0700
Subject: tun: allow positive return values on dev_get_valid_name() call
From: Julien Gomes <julien(a)arista.com>
[ Upstream commit 5c25f65fd1e42685f7ccd80e0621829c105785d9 ]
If the name argument of dev_get_valid_name() contains "%d", it will try
to assign it a unit number in __dev__alloc_name() and return either the
unit number (>= 0) or an error code (< 0).
Considering positive values as error values prevent tun device creations
relying this mechanism, therefor we should only consider negative values
as errors here.
Signed-off-by: Julien Gomes <julien(a)arista.com>
Acked-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/tun.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1685,7 +1685,7 @@ static int tun_set_iff(struct net *net,
if (!dev)
return -ENOMEM;
err = dev_get_valid_name(net, dev, name);
- if (err)
+ if (err < 0)
goto err_free_dev;
dev_net_set(dev, net);
Patches currently in stable-queue which might be from julien(a)arista.com are
queue-4.4/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
This is a note to let you know that I've just added the patch titled
tcp: fix tcp_mtu_probe() vs highest_sack
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Mon, 30 Oct 2017 23:08:20 -0700
Subject: tcp: fix tcp_mtu_probe() vs highest_sack
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 2b7cda9c35d3b940eb9ce74b30bbd5eb30db493d ]
Based on SNMP values provided by Roman, Yuchung made the observation
that some crashes in tcp_sacktag_walk() might be caused by MTU probing.
Looking at tcp_mtu_probe(), I found that when a new skb was placed
in front of the write queue, we were not updating tcp highest sack.
If one skb is freed because all its content was copied to the new skb
(for MTU probing), then tp->highest_sack could point to a now freed skb.
Bad things would then happen, including infinite loops.
This patch renames tcp_highest_sack_combine() and uses it
from tcp_mtu_probe() to fix the bug.
Note that I also removed one test against tp->sacked_out,
since we want to replace tp->highest_sack regardless of whatever
condition, since keeping a stale pointer to freed skb is a recipe
for disaster.
Fixes: a47e5a988a57 ("[TCP]: Convert highest_sack to sk_buff to allow direct access")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Alexei Starovoitov <alexei.starovoitov(a)gmail.com>
Reported-by: Roman Gushchin <guro(a)fb.com>
Reported-by: Oleksandr Natalenko <oleksandr(a)natalenko.name>
Acked-by: Alexei Starovoitov <ast(a)kernel.org>
Acked-by: Neal Cardwell <ncardwell(a)google.com>
Acked-by: Yuchung Cheng <ycheng(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/tcp.h | 6 +++---
net/ipv4/tcp_output.c | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1612,12 +1612,12 @@ static inline void tcp_highest_sack_rese
tcp_sk(sk)->highest_sack = tcp_write_queue_head(sk);
}
-/* Called when old skb is about to be deleted (to be combined with new skb) */
-static inline void tcp_highest_sack_combine(struct sock *sk,
+/* Called when old skb is about to be deleted and replaced by new skb */
+static inline void tcp_highest_sack_replace(struct sock *sk,
struct sk_buff *old,
struct sk_buff *new)
{
- if (tcp_sk(sk)->sacked_out && (old == tcp_sk(sk)->highest_sack))
+ if (old == tcp_highest_sack(sk))
tcp_sk(sk)->highest_sack = new;
}
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1951,6 +1951,7 @@ static int tcp_mtu_probe(struct sock *sk
nskb->ip_summed = skb->ip_summed;
tcp_insert_write_queue_before(nskb, skb, sk);
+ tcp_highest_sack_replace(sk, skb, nskb);
len = 0;
tcp_for_write_queue_from_safe(skb, next, sk) {
@@ -2464,7 +2465,7 @@ static void tcp_collapse_retrans(struct
BUG_ON(tcp_skb_pcount(skb) != 1 || tcp_skb_pcount(next_skb) != 1);
- tcp_highest_sack_combine(sk, next_skb, skb);
+ tcp_highest_sack_replace(sk, next_skb, skb);
tcp_unlink_write_queue(next_skb, sk);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.4/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.4/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
sctp: reset owner sk for data chunks on out queues when migrating a sock
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Sat, 28 Oct 2017 02:13:29 +0800
Subject: sctp: reset owner sk for data chunks on out queues when migrating a sock
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit d04adf1b355181e737b6b1e23d801b07f0b7c4c0 ]
Now when migrating sock to another one in sctp_sock_migrate(), it only
resets owner sk for the data in receive queues, not the chunks on out
queues.
It would cause that data chunks length on the sock is not consistent
with sk sk_wmem_alloc. When closing the sock or freeing these chunks,
the old sk would never be freed, and the new sock may crash due to
the overflow sk_wmem_alloc.
syzbot found this issue with this series:
r0 = socket$inet_sctp()
sendto$inet(r0)
listen(r0)
accept4(r0)
close(r0)
Although listen() should have returned error when one TCP-style socket
is in connecting (I may fix this one in another patch), it could also
be reproduced by peeling off an assoc.
This issue is there since very beginning.
This patch is to reset owner sk for the chunks on out queues so that
sk sk_wmem_alloc has correct value after accept one sock or peeloff
an assoc to one sock.
Note that when resetting owner sk for chunks on outqueue, it has to
sctp_clear_owner_w/skb_orphan chunks before changing assoc->base.sk
first and then sctp_set_owner_w them after changing assoc->base.sk,
due to that sctp_wfree and it's callees are using assoc->base.sk.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -168,6 +168,36 @@ static inline void sctp_set_owner_w(stru
sk_mem_charge(sk, chunk->skb->truesize);
}
+static void sctp_clear_owner_w(struct sctp_chunk *chunk)
+{
+ skb_orphan(chunk->skb);
+}
+
+static void sctp_for_each_tx_datachunk(struct sctp_association *asoc,
+ void (*cb)(struct sctp_chunk *))
+
+{
+ struct sctp_outq *q = &asoc->outqueue;
+ struct sctp_transport *t;
+ struct sctp_chunk *chunk;
+
+ list_for_each_entry(t, &asoc->peer.transport_addr_list, transports)
+ list_for_each_entry(chunk, &t->transmitted, transmitted_list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->retransmit, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->sacked, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->abandoned, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->out_chunk_list, list)
+ cb(chunk);
+}
+
/* Verify that this is a valid address. */
static inline int sctp_verify_addr(struct sock *sk, union sctp_addr *addr,
int len)
@@ -7362,7 +7392,9 @@ static void sctp_sock_migrate(struct soc
* paths won't try to lock it and then oldsk.
*/
lock_sock_nested(newsk, SINGLE_DEPTH_NESTING);
+ sctp_for_each_tx_datachunk(assoc, sctp_clear_owner_w);
sctp_assoc_migrate(assoc, newsk);
+ sctp_for_each_tx_datachunk(assoc, sctp_set_owner_w);
/* If the association on the newsk is already closed before accept()
* is called, set RCV_SHUTDOWN flag.
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.4/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
This is a note to let you know that I've just added the patch titled
sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Wed, 18 Oct 2017 21:37:49 +0800
Subject: sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 1cc276cec9ec574d41cf47dfc0f51406b6f26ab4 ]
Now sctp processes icmp redirect packet in sctp_icmp_redirect where
it calls sctp_transport_dst_check in which tp->dst can be released.
The problem is before calling sctp_transport_dst_check, it doesn't
check sock_owned_by_user, which means tp->dst could be freed while
a process is accessing it with owning the socket.
An use-after-free issue could be triggered by this.
This patch is to fix it by checking sock_owned_by_user before calling
sctp_transport_dst_check in sctp_icmp_redirect, so that it would not
release tp->dst if users still hold sock lock.
Besides, the same issue fixed in commit 45caeaa5ac0b ("dccp/tcp: fix
routing redirect race") on sctp also needs this check.
Fixes: 55be7a9c6074 ("ipv4: Add redirect support to all protocol icmp error handlers")
Reported-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -420,7 +420,7 @@ void sctp_icmp_redirect(struct sock *sk,
{
struct dst_entry *dst;
- if (!t)
+ if (sock_owned_by_user(sk) || !t)
return;
dst = sctp_transport_dst_check(t);
if (dst)
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.4/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
This is a note to let you know that I've just added the patch titled
ppp: fix race in ppp device destruction
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ppp-fix-race-in-ppp-device-destruction.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Guillaume Nault <g.nault(a)alphalink.fr>
Date: Fri, 6 Oct 2017 17:05:49 +0200
Subject: ppp: fix race in ppp device destruction
From: Guillaume Nault <g.nault(a)alphalink.fr>
[ Upstream commit 6151b8b37b119e8e3a8401b080d532520c95faf4 ]
ppp_release() tries to ensure that netdevices are unregistered before
decrementing the unit refcount and running ppp_destroy_interface().
This is all fine as long as the the device is unregistered by
ppp_release(): the unregister_netdevice() call, followed by
rtnl_unlock(), guarantee that the unregistration process completes
before rtnl_unlock() returns.
However, the device may be unregistered by other means (like
ppp_nl_dellink()). If this happens right before ppp_release() calling
rtnl_lock(), then ppp_release() has to wait for the concurrent
unregistration code to release the lock.
But rtnl_unlock() releases the lock before completing the device
unregistration process. This allows ppp_release() to proceed and
eventually call ppp_destroy_interface() before the unregistration
process completes. Calling free_netdev() on this partially unregistered
device will BUG():
------------[ cut here ]------------
kernel BUG at net/core/dev.c:8141!
invalid opcode: 0000 [#1] SMP
CPU: 1 PID: 1557 Comm: pppd Not tainted 4.14.0-rc2+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014
Call Trace:
ppp_destroy_interface+0xd8/0xe0 [ppp_generic]
ppp_disconnect_channel+0xda/0x110 [ppp_generic]
ppp_unregister_channel+0x5e/0x110 [ppp_generic]
pppox_unbind_sock+0x23/0x30 [pppox]
pppoe_connect+0x130/0x440 [pppoe]
SYSC_connect+0x98/0x110
? do_fcntl+0x2c0/0x5d0
SyS_connect+0xe/0x10
entry_SYSCALL_64_fastpath+0x1a/0xa5
RIP: free_netdev+0x107/0x110 RSP: ffffc28a40573d88
---[ end trace ed294ff0cc40eeff ]---
We could set the ->needs_free_netdev flag on PPP devices and move the
ppp_destroy_interface() logic in the ->priv_destructor() callback. But
that'd be quite intrusive as we'd first need to unlink from the other
channels and units that depend on the device (the ones that used the
PPPIOCCONNECT and PPPIOCATTACH ioctls).
Instead, we can just let the netdevice hold a reference on its
ppp_file. This reference is dropped in ->priv_destructor(), at the very
end of the unregistration process, so that neither ppp_release() nor
ppp_disconnect_channel() can call ppp_destroy_interface() in the interim.
Reported-by: Beniamino Galvani <bgalvani(a)redhat.com>
Fixes: 8cb775bc0a34 ("ppp: fix device unregistration upon netns deletion")
Signed-off-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ppp/ppp_generic.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -1110,7 +1110,17 @@ ppp_get_stats64(struct net_device *dev,
static struct lock_class_key ppp_tx_busylock;
static int ppp_dev_init(struct net_device *dev)
{
+ struct ppp *ppp;
+
dev->qdisc_tx_busylock = &ppp_tx_busylock;
+
+ ppp = netdev_priv(dev);
+ /* Let the netdevice take a reference on the ppp file. This ensures
+ * that ppp_destroy_interface() won't run before the device gets
+ * unregistered.
+ */
+ atomic_inc(&ppp->file.refcnt);
+
return 0;
}
@@ -1133,6 +1143,15 @@ static void ppp_dev_uninit(struct net_de
wake_up_interruptible(&ppp->file.rwait);
}
+static void ppp_dev_priv_destructor(struct net_device *dev)
+{
+ struct ppp *ppp;
+
+ ppp = netdev_priv(dev);
+ if (atomic_dec_and_test(&ppp->file.refcnt))
+ ppp_destroy_interface(ppp);
+}
+
static const struct net_device_ops ppp_netdev_ops = {
.ndo_init = ppp_dev_init,
.ndo_uninit = ppp_dev_uninit,
@@ -1150,6 +1169,7 @@ static void ppp_setup(struct net_device
dev->tx_queue_len = 3;
dev->type = ARPHRD_PPP;
dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
+ dev->destructor = ppp_dev_priv_destructor;
netif_keep_dst(dev);
}
Patches currently in stable-queue which might be from g.nault(a)alphalink.fr are
queue-4.4/ppp-fix-race-in-ppp-device-destruction.patch
queue-4.4/l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
This is a note to let you know that I've just added the patch titled
packet: avoid panic in packet_getsockopt()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
packet-avoid-panic-in-packet_getsockopt.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 18 Oct 2017 16:14:52 -0700
Subject: packet: avoid panic in packet_getsockopt()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 509c7a1ecc8601f94ffba8a00889fefb239c00c6 ]
syzkaller got crashes in packet_getsockopt() processing
PACKET_ROLLOVER_STATS command while another thread was managing
to change po->rollover
Using RCU will fix this bug. We might later add proper RCU annotations
for sparse sake.
In v2: I replaced kfree(rollover) in fanout_add() to kfree_rcu()
variant, as spotted by John.
Fixes: a9b6391814d5 ("packet: rollover statistics")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: Willem de Bruijn <willemb(a)google.com>
Cc: John Sperbeck <jsperbeck(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/packet/af_packet.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1724,7 +1724,7 @@ static int fanout_add(struct sock *sk, u
out:
if (err && rollover) {
- kfree(rollover);
+ kfree_rcu(rollover, rcu);
po->rollover = NULL;
}
mutex_unlock(&fanout_mutex);
@@ -1751,8 +1751,10 @@ static struct packet_fanout *fanout_rele
else
f = NULL;
- if (po->rollover)
+ if (po->rollover) {
kfree_rcu(po->rollover, rcu);
+ po->rollover = NULL;
+ }
}
mutex_unlock(&fanout_mutex);
@@ -3769,6 +3771,7 @@ static int packet_getsockopt(struct sock
void *data = &val;
union tpacket_stats_u st;
struct tpacket_rollover_stats rstats;
+ struct packet_rollover *rollover;
if (level != SOL_PACKET)
return -ENOPROTOOPT;
@@ -3847,13 +3850,18 @@ static int packet_getsockopt(struct sock
0);
break;
case PACKET_ROLLOVER_STATS:
- if (!po->rollover)
+ rcu_read_lock();
+ rollover = rcu_dereference(po->rollover);
+ if (rollover) {
+ rstats.tp_all = atomic_long_read(&rollover->num);
+ rstats.tp_huge = atomic_long_read(&rollover->num_huge);
+ rstats.tp_failed = atomic_long_read(&rollover->num_failed);
+ data = &rstats;
+ lv = sizeof(rstats);
+ }
+ rcu_read_unlock();
+ if (!rollover)
return -EINVAL;
- rstats.tp_all = atomic_long_read(&po->rollover->num);
- rstats.tp_huge = atomic_long_read(&po->rollover->num_huge);
- rstats.tp_failed = atomic_long_read(&po->rollover->num_failed);
- data = &rstats;
- lv = sizeof(rstats);
break;
case PACKET_TX_HAS_OFF:
val = po->tp_tx_has_off;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.4/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.4/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
net/unix: don't show information about sockets from other namespaces
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Andrei Vagin <avagin(a)openvz.org>
Date: Wed, 25 Oct 2017 10:16:42 -0700
Subject: net/unix: don't show information about sockets from other namespaces
From: Andrei Vagin <avagin(a)openvz.org>
[ Upstream commit 0f5da659d8f1810f44de14acf2c80cd6499623a0 ]
socket_diag shows information only about sockets from a namespace where
a diag socket lives.
But if we request information about one unix socket, the kernel don't
check that its netns is matched with a diag socket namespace, so any
user can get information about any unix socket in a system. This looks
like a bug.
v2: add a Fixes tag
Fixes: 51d7cccf0723 ("net: make sock diag per-namespace")
Signed-off-by: Andrei Vagin <avagin(a)openvz.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/unix/diag.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -257,6 +257,8 @@ static int unix_diag_get_exact(struct sk
err = -ENOENT;
if (sk == NULL)
goto out_nosk;
+ if (!net_eq(sock_net(sk), net))
+ goto out;
err = sock_diag_check_cookie(sk, req->udiag_cookie);
if (err)
Patches currently in stable-queue which might be from avagin(a)openvz.org are
queue-4.4/net-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
This is a note to let you know that I've just added the patch titled
l2tp: check ps->sock before running pppol2tp_session_ioctl()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Guillaume Nault <g.nault(a)alphalink.fr>
Date: Fri, 13 Oct 2017 19:22:35 +0200
Subject: l2tp: check ps->sock before running pppol2tp_session_ioctl()
From: Guillaume Nault <g.nault(a)alphalink.fr>
[ Upstream commit 5903f594935a3841137c86b9d5b75143a5b7121c ]
When pppol2tp_session_ioctl() is called by pppol2tp_tunnel_ioctl(),
the session may be unconnected. That is, it was created by
pppol2tp_session_create() and hasn't been connected with
pppol2tp_connect(). In this case, ps->sock is NULL, so we need to check
for this case in order to avoid dereferencing a NULL pointer.
Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_ppp.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -1015,6 +1015,9 @@ static int pppol2tp_session_ioctl(struct
session->name, cmd, arg);
sk = ps->sock;
+ if (!sk)
+ return -EBADR;
+
sock_hold(sk);
switch (cmd) {
Patches currently in stable-queue which might be from g.nault(a)alphalink.fr are
queue-4.4/ppp-fix-race-in-ppp-device-destruction.patch
queue-4.4/l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
This is a note to let you know that I've just added the patch titled
ipv6: flowlabel: do not leave opt->tot_len with garbage
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Sat, 21 Oct 2017 12:26:23 -0700
Subject: ipv6: flowlabel: do not leave opt->tot_len with garbage
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 864e2a1f8aac05effac6063ce316b480facb46ff ]
When syzkaller team brought us a C repro for the crash [1] that
had been reported many times in the past, I finally could find
the root cause.
If FlowLabel info is merged by fl6_merge_options(), we leave
part of the opt_space storage provided by udp/raw/l2tp with random value
in opt_space.tot_len, unless a control message was provided at sendmsg()
time.
Then ip6_setup_cork() would use this random value to perform a kzalloc()
call. Undefined behavior and crashes.
Fix is to properly set tot_len in fl6_merge_options()
At the same time, we can also avoid consuming memory and cpu cycles
to clear it, if every option is copied via a kmemdup(). This is the
change in ip6_setup_cork().
[1]
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 6613 Comm: syz-executor0 Not tainted 4.14.0-rc4+ #127
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801cb64a100 task.stack: ffff8801cc350000
RIP: 0010:ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168
RSP: 0018:ffff8801cc357550 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: ffff8801cc357748 RCX: 0000000000000010
RDX: 0000000000000002 RSI: ffffffff842bd1d9 RDI: 0000000000000014
RBP: ffff8801cc357620 R08: ffff8801cb17f380 R09: ffff8801cc357b10
R10: ffff8801cb64a100 R11: 0000000000000000 R12: ffff8801cc357ab0
R13: ffff8801cc357b10 R14: 0000000000000000 R15: ffff8801c3bbf0c0
FS: 00007f9c5c459700(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020324000 CR3: 00000001d1cf2000 CR4: 00000000001406f0
DR0: 0000000020001010 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Call Trace:
ip6_make_skb+0x282/0x530 net/ipv6/ip6_output.c:1729
udpv6_sendmsg+0x2769/0x3380 net/ipv6/udp.c:1340
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
SYSC_sendto+0x358/0x5a0 net/socket.c:1750
SyS_sendto+0x40/0x50 net/socket.c:1718
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4520a9
RSP: 002b:00007f9c5c458c08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004520a9
RDX: 0000000000000001 RSI: 0000000020fd1000 RDI: 0000000000000016
RBP: 0000000000000086 R08: 0000000020e0afe4 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004bb1ee
R13: 00000000ffffffff R14: 0000000000000016 R15: 0000000000000029
Code: e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 0f 00 00 48 8d 79 04 48 b8 00 00 00 00 00 fc ff df 45 8b 74 24 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RIP: ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168 RSP: ffff8801cc357550
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_output.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -315,6 +315,7 @@ struct ipv6_txoptions *fl6_merge_options
}
opt_space->dst1opt = fopt->dst1opt;
opt_space->opt_flen = fopt->opt_flen;
+ opt_space->tot_len = fopt->tot_len;
return opt_space;
}
EXPORT_SYMBOL_GPL(fl6_merge_options);
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1201,11 +1201,11 @@ static int ip6_setup_cork(struct sock *s
if (WARN_ON(v6_cork->opt))
return -EINVAL;
- v6_cork->opt = kzalloc(opt->tot_len, sk->sk_allocation);
+ v6_cork->opt = kzalloc(sizeof(*opt), sk->sk_allocation);
if (unlikely(!v6_cork->opt))
return -ENOBUFS;
- v6_cork->opt->tot_len = opt->tot_len;
+ v6_cork->opt->tot_len = sizeof(*opt);
v6_cork->opt->opt_flen = opt->opt_flen;
v6_cork->opt->opt_nflen = opt->opt_nflen;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.4/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.4/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:08:14 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Thu, 26 Oct 2017 19:23:27 +0800
Subject: ip6_gre: only increase err_count for some certain type icmpv6 in ip6gre_err
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit f8d20b46ce55cf40afb30dcef6d9288f7ef46d9b ]
The similar fix in patch 'ipip: only increase err_count for some
certain type icmp in ipip_err' is needed for ip6gre_err.
In Jianlin's case, udp netperf broke even when receiving a TooBig
icmpv6 packet.
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_gre.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -409,13 +409,16 @@ static void ip6gre_err(struct sk_buff *s
case ICMPV6_DEST_UNREACH:
net_dbg_ratelimited("%s: Path to destination invalid or inactive!\n",
t->parms.name);
- break;
+ if (code != ICMPV6_PORT_UNREACH)
+ break;
+ return;
case ICMPV6_TIME_EXCEED:
if (code == ICMPV6_EXC_HOPLIMIT) {
net_dbg_ratelimited("%s: Too small hop limit or routing loop in tunnel!\n",
t->parms.name);
+ break;
}
- break;
+ return;
case ICMPV6_PARAMPROB:
teli = 0;
if (code == ICMPV6_HDR_FIELD)
@@ -431,13 +434,13 @@ static void ip6gre_err(struct sk_buff *s
net_dbg_ratelimited("%s: Recipient unable to parse tunneled packet!\n",
t->parms.name);
}
- break;
+ return;
case ICMPV6_PKT_TOOBIG:
mtu = be32_to_cpu(info) - offset;
if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
t->dev->mtu = mtu;
- break;
+ return;
}
if (time_before(jiffies, t->err_time + IP6TUNNEL_ERR_TIMEO))
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.4/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
This is a note to let you know that I've just added the patch titled
Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2cfe61144e9d770ed3e0556257e9dcc469ca14cf Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Thu, 16 Nov 2017 14:29:13 +0100
Subject: Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts commit 62b9fa2c436ffd9b87e6ed81df7f86c29fee092b which is
commit 8b649e426336d7d4800ff9c82858328f4215ba01 upstream.
Turns out not to be a good idea in the stable kernels for now as Patrick
writes:
As discussed for 4.4 stable queue this patch might break
existing machines, if they use a different pinmux configuration
with their own bootloader.
Reported-by: Patrick Brünn <P.Bruenn(a)beckhoff.com>
Cc: Shawn Guo <shawnguo(a)kernel.org>
Cc: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman gregkh(a)linuxfoundation.org
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
pinctrl_fec: fecgrp {
fsl,pins = <
- MX53_PAD_FEC_MDC__FEC_MDC 0x4
- MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
- MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180
- MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180
- MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180
- MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180
- MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180
- MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4
- MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4
- MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4
+ MX53_PAD_FEC_MDC__FEC_MDC 0x80000000
+ MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000
+ MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
+ MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000
+ MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000
+ MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000
+ MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000
+ MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
+ MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000
+ MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000
>;
};
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-4.9/net-call-cgroup_sk_alloc-earlier-in-sk_clone_lock.patch
queue-4.9/tcp-dccp-fix-ireq-opt-races.patch
queue-4.9/soreuseport-fix-initialization-race.patch
queue-4.9/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.9/input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
queue-4.9/revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
queue-4.9/mac80211-use-constant-time-comparison-with-keys.patch
queue-4.9/ipv6-addrconf-increment-ifp-refcount-before-ipv6_del_addr.patch
queue-4.9/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.9/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-4.9/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.9/sctp-full-support-for-ipv6-ip_nonlocal_bind-ip_freebind.patch
queue-4.9/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.9/tun-call-dev_get_valid_name-before-register_netdevice.patch
queue-4.9/gso-fix-payload-length-when-gso_size-is-zero.patch
queue-4.9/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.9/net_sched-avoid-matching-qdisc-with-zero-handle.patch
queue-4.9/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
queue-4.9/ip6_gre-update-dst-pmtu-if-dev-mtu-has-been-updated-by-toobig-in-__gre6_xmit.patch
queue-4.9/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.9/alsa-seq-cancel-pending-autoload-work-at-unbinding-device.patch
queue-4.9/tap-double-free-in-error-path-in-tap_open.patch
queue-4.9/ppp-fix-race-in-ppp-device-destruction.patch
queue-4.9/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.9/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-4.9/l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
queue-4.9/netlink-do-not-set-cb_running-if-dump-s-start-errs.patch
queue-4.9/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
queue-4.9/mac80211-accept-key-reinstall-without-changing-anything.patch
queue-4.9/usb-usbtest-fix-null-pointer-dereference.patch
queue-4.9/net-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
queue-4.9/tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
This is a note to let you know that I've just added the patch titled
Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2cfe61144e9d770ed3e0556257e9dcc469ca14cf Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Thu, 16 Nov 2017 14:29:13 +0100
Subject: Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This reverts commit 2eb85ef18c6570e8a59643cd8d5a66122461b1fc which is
commit 8b649e426336d7d4800ff9c82858328f4215ba01 upstream.
Turns out not to be a good idea in the stable kernels for now as Patrick
writes:
As discussed for 4.4 stable queue this patch might break
existing machines, if they use a different pinmux configuration
with their own bootloader.
Reported-by: Patrick Brünn <P.Bruenn(a)beckhoff.com>
Cc: Shawn Guo <shawnguo(a)kernel.org>
Cc: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman gregkh(a)linuxfoundation.org
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -215,16 +215,16 @@
pinctrl_fec: fecgrp {
fsl,pins = <
- MX53_PAD_FEC_MDC__FEC_MDC 0x4
- MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc
- MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180
- MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180
- MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180
- MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180
- MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180
- MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4
- MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4
- MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4
+ MX53_PAD_FEC_MDC__FEC_MDC 0x80000000
+ MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000
+ MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000
+ MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000
+ MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000
+ MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000
+ MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000
+ MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
+ MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000
+ MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000
>;
};
Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are
queue-3.18/input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
queue-3.18/revert-arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch
queue-3.18/mac80211-use-constant-time-comparison-with-keys.patch
queue-3.18/revert-ceph-unlock-dangling-spinlock-in-try_flush_caps.patch
queue-3.18/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-3.18/mac80211-accept-key-reinstall-without-changing-anything.patch
queue-3.18/usb-usbtest-fix-null-pointer-dereference.patch
Hi Aditya,
My problem is fixed with this patch. WILC1000 connects to AP,
IP is retrieved from DHCP server and ping works. You can add my
Tested-by: Claudiu Beznea <claudiu.beznea(a)microchip.com>
Thanks,
Claudiu
On 03.11.2017 10:56, Aditya Shankar wrote:
> Commit 46949b48568b ("staging: wilc1000: New cfg packet
> format in handle_set_wfi_drv_handler") updated the frame
> format sent from host to the firmware. The code to update
> the bssid offset in the new frame was part of a second
> patch in the series which did not make it in and thus
> causes connection problems after associating to an AP.
>
> This fix adds the proper offset of the bssid value in the
> Tx queue buffer to fix the connection issues.
>
> Fixes: Commit 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler")
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Aditya Shankar <Aditya.Shankar(a)microchip.com>
> ---
> drivers/staging/wilc1000/wilc_wlan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
> index 9addef1..f49dfa8 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -714,7 +714,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count)
> char *bssid = ((struct tx_complete_data *)(tqe->priv))->bssid;
>
> buffer_offset = ETH_ETHERNET_HDR_OFFSET;
> - memcpy(&txb[offset + 4], bssid, 6);
> + memcpy(&txb[offset + 8], bssid, 6);
> } else {
> buffer_offset = HOST_HDR_OFFSET;
> }
>
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Greg-KH,
Here are three target patches for v3.10.y stable, the first of which
did not originally include a stable CC, and the latter two did not
apply due to a minor context change.
The series has been cut against v3.10.108. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Mikulas Patocka (1):
iscsi-target: fix iscsit_del_np deadlock on unload
Nicholas Bellinger (1):
iscsi-target: Fix iscsi_np reset hung task during parallel delete
drivers/target/iscsi/iscsi_target.c | 20 ++++++++------------
drivers/target/iscsi/iscsi_target_core.h | 1 +
drivers/target/iscsi/iscsi_target_login.c | 25 ++++++++++++-------------
include/target/target_core_base.h | 1 +
4 files changed, 22 insertions(+), 25 deletions(-)
--
1.8.5.3
2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글:
> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
> are contiguous, because of the underlying dma_alloc_attrs() function
> provides only such buffers. In such case it makes no sense to keep
What if user disabled CMA support? In this case, it guarantees also to allocate physically contiguous memory?
I think it depends on CMA support so wouldn't be true.
Real problem I think is that user don't know whether the gem buffer allocated with CONTIG or NONCONTIG flag can be used as a SCANOUT buffer.
So user can request a page flip with NONCONTIG buffer to kernel which doesn't support IOMMU.
And another is that user may want to use NONCONTIG buffer for another purpose, not scanout.
So if we enforce on using CONTIG buffer on kernel without IOMMU support, then it wouldn't be really what user intended.
My idea is to provide a new flag - i.e., EXYNOS_BO_SCANOUT - which can allocate a buffer with a different allocation type - CONTIG or NONCONTIG - according to IOMMU support.
And any page flip request with NONCONTIG buffer to kernel without IOMMU support should fail and it has to return a error with a proper error message.
> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
> failures for buffer contiguity checks in the subsequent operations on GEM
> objects.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
> CC: stable(a)vger.kernel.org # v4.4+
> ---
> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
> support for exynos drm framework"), but this patch applies cleanly
> only to v4.4+ kernel releases due changes in the surrounding code.
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 02f978bb9261..476c00fe1998 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -227,6 +227,13 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct drm_device *dev,
> if (IS_ERR(exynos_gem))
> return exynos_gem;
>
> + /*
> + * when no IOMMU is available, all allocated buffers are contiguous
> + * anyway, so drop EXYNOS_BO_NONCONTIG flag
> + */
> + if (!is_drm_iommu_supported(dev))
> + flags &= ~EXYNOS_BO_NONCONTIG;
So this could be a tempararily solution until the new flag is added, and you may need to modify above comments.
Thanks,
Inki Dae
> +
> /* set memory type and cache attribute from user side. */
> exynos_gem->flags = flags;
>
>
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Sasha,
Here are a target patches outstanding for v4.1.y stable. Note that
some of these had not been merged from the last v4.1.y series posted
here:
http://www.spinics.net/lists/target-devel/msg15916.html
Please ensure these get picked up for the next v4.1.y release.
The series has been cut against v4.1.45. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Jiang Yi (1):
iscsi-target: Always wait for kthread_should_stop() before kthread
exit
Nicholas Bellinger (5):
target: Obtain se_node_acl->acl_kref during get_initiator_node_acl
target: Fix multi-session dynamic se_node_acl double free OOPs
target: Avoid mappedlun symlink creation during lun shutdown
Revert "target: Fix VERIFY and WRITE VERIFY command parsing"
target: Fix node_acl demo-mode + uncached dynamic shutdown regression
drivers/target/iscsi/iscsi_target.c | 49 ++++++++++------
drivers/target/iscsi/iscsi_target_erl0.c | 6 +-
drivers/target/iscsi/iscsi_target_erl0.h | 2 +-
drivers/target/iscsi/iscsi_target_login.c | 4 ++
drivers/target/target_core_fabric_configfs.c | 5 ++
drivers/target/target_core_sbc.c | 71 +++-------------------
drivers/target/target_core_tpg.c | 51 ++++++++++++++--
drivers/target/target_core_transport.c | 88 ++++++++++++++++++----------
include/target/target_core_base.h | 3 +
include/target/target_core_fabric.h | 2 +
10 files changed, 163 insertions(+), 118 deletions(-)
--
1.8.5.3
This is the start of the stable review cycle for the 3.18.81 release.
There are 28 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Nov 15 12:53:41 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.81-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.81-rc1
Borislav Petkov <bp(a)suse.de>
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
Richard Schütz <rschuetz(a)uni-koblenz.de>
can: c_can: don't indicate triple sampling support for D_CAN
Ilya Dryomov <idryomov(a)gmail.com>
rbd: use GFP_NOIO for parent stat and data requests
Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de>
MIPS: AR7: Ensure that serial ports are properly set up
Paul Burton <paul.burton(a)mips.com>
MIPS: Fix CM region target definitions
Gustavo A. R. Silva <garsilva(a)embeddedor.com>
MIPS: microMIPS: Fix incorrect mask in insn_table_MM
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Avoid invalid lockdep class warning
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix OSS sysex delivery in OSS emulation
Mark Rutland <mark.rutland(a)arm.com>
ARM: 8720/1: ensure dump_instr() checks addr_limit
Eric Biggers <ebiggers(a)google.com>
KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]
Andrey Ryabinin <aryabinin(a)virtuozzo.com>
crypto: x86/sha1-mb - fix panic due to unaligned access
Eric Biggers <ebiggers(a)google.com>
KEYS: trusted: fix writing past end of buffer in trusted_read()
Eric Biggers <ebiggers(a)google.com>
KEYS: trusted: sanitize all key material
Feras Daoud <ferasda(a)mellanox.com>
IB/ipoib: Change list_del to list_del_init in the tx object
Akinobu Mita <akinobu.mita(a)gmail.com>
Input: mpr121 - set missing event capability
Akinobu Mita <akinobu.mita(a)gmail.com>
Input: mpr121 - handle multiple bits change of status register
Gilad Ben-Yossef <gilad(a)benyossef.com>
IPsec: do not ignore crypto err in ah4 input
William wu <wulf(a)rock-chips.com>
usb: hcd: initialize hcd->flags to 0 when rm hcd
Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com>
serial: sh-sci: Fix register offsets for the IRDA serial port
Volodymyr Bendiuga <volodymyr.bendiuga(a)gmail.com>
phy: increase size of MII_BUS_ID_SIZE and bus_id
David Lechner <david(a)lechnology.com>
dt-bindings: Add vendor prefix for LEGO
David Lechner <david(a)lechnology.com>
dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
Alison Schofield <amsfield22(a)gmail.com>
iio: trigger: free trigger resource correctly
Tony Lindgren <tony(a)atomide.com>
ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
Noralf Trønnes <noralf(a)tronnes.org>
drm: drm_minor_register(): Clean up debugfs on failure
Patrick Bruenn <p.bruenn(a)beckhoff.com>
ARM: dts: imx53-qsb-common: fix FEC pinmux config
Juergen Gross <jgross(a)suse.com>
xen/netback: set default upper limit of tx/rx queues to 8
Maciej W. Rozycki <macro(a)linux-mips.org>
video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
-------------
Diffstat:
Documentation/devicetree/bindings/arm/davinci.txt | 4 ++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
Makefile | 4 +-
arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 +++----
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/kernel/traps.c | 28 +++++----
arch/mips/ar7/platform.c | 1 +
arch/mips/include/asm/mips-cm.h | 4 +-
arch/mips/mm/uasm-micromips.c | 2 +-
arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 -
arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 12 ++--
arch/x86/oprofile/op_model_ppro.c | 4 +-
drivers/block/rbd.c | 4 +-
drivers/gpu/drm/drm_drv.c | 2 +-
drivers/iio/trigger/iio-trig-interrupt.c | 8 +--
drivers/iio/trigger/iio-trig-sysfs.c | 2 +-
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +-
drivers/input/keyboard/mpr121_touchkey.c | 24 +++++---
drivers/net/can/c_can/c_can_pci.c | 1 -
drivers/net/can/c_can/c_can_platform.c | 1 -
drivers/net/xen-netback/netback.c | 6 +-
drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 +-
drivers/tty/serial/sh-sci.c | 17 +++---
drivers/usb/core/hcd.c | 1 +
drivers/video/fbdev/pmag-ba-fb.c | 2 +-
include/linux/phy.h | 8 +--
include/sound/seq_kernel.h | 3 +-
lib/asn1_decoder.c | 4 +-
net/ipv4/ah4.c | 3 +
security/keys/trusted.c | 70 ++++++++++------------
sound/core/seq/oss/seq_oss_midi.c | 4 +-
sound/core/seq/oss/seq_oss_readq.c | 29 +++++++++
sound/core/seq/oss/seq_oss_readq.h | 2 +
33 files changed, 162 insertions(+), 117 deletions(-)
On Thu, Nov 09, 2017 at 12:40:36PM +0000, Ben Hutchings wrote:
> On Thu, 2017-11-09 at 13:21 +0100, Arnd Bergmann wrote:
> > On Thu, Nov 9, 2017 at 1:08 PM, Greg KH <greg(a)kroah.com> wrote:
> > > On Thu, Nov 09, 2017 at 12:55:30PM +0100, Arnd Bergmann wrote:
> [...]
> > > > I think if you upload the branch to the stable-rc git, that should produce
> > > > the automated build and boot results via email or via the
> > > > https://kernelci.org/job/ interface. Once there are some results
> > > > there, I'll go through the list once more to see what warnings
> > > > and failures remain.
> > >
> > > I don't know of a way to have others push to that tree/branch at the
> > > moment :(
> > >
> > > I'll go update that branch now...
> >
> > Thanks!
> >
> > With the arm-soc tree, we simply have a shared group-id on
> > gitolite.kernel.org and everyone in that group can push to it.
> >
> > If that is the only thing you need, it should be trivial to let Ben
> > and Sasha push to /pub/scm/linux/kernel/git/stable/*.git as well,
> > I'm sure helpdesk(a)kernel.org can arrange that. Of course if you are
> > worried about having multiple accounts with write access to all the
> > branches, then that wouldn't be enough.
>
> I think I'd rather send a pull request to Greg at the start of the
> review period.
That works for me!
From: Jaewon Kim <jaewon31.kim(a)samsung.com>
Subject: mm/page_ext.c: check if page_ext is not prepared
online_page_ext() and page_ext_init() allocate page_ext for each section,
but they do not allocate if the first PFN is !pfn_present(pfn) or
!pfn_valid(pfn). Then section->page_ext remains as NULL. lookup_page_ext
checks NULL only if CONFIG_DEBUG_VM is enabled. For a valid PFN,
__set_page_owner will try to get page_ext through lookup_page_ext.
Without CONFIG_DEBUG_VM lookup_page_ext will misuse NULL pointer as value
0. This incurrs invalid address access.
This is the panic example when PFN 0x100000 is not valid but PFN 0x13FC00
is being used for page_ext. section->page_ext is NULL, get_entry returned
invalid page_ext address as 0x1DFA000 for a PFN 0x13FC00.
To avoid this panic, CONFIG_DEBUG_VM should be removed so that page_ext
will be checked at all times.
<1>[ 11.618085] Unable to handle kernel paging request at virtual address 01dfa014
<1>[ 11.618140] pgd = ffffffc0c6dc9000
<1>[ 11.618174] [01dfa014] *pgd=0000000000000000, *pud=0000000000000000
<4>[ 11.618240] ------------[ cut here ]------------
<2>[ 11.618278] Kernel BUG at ffffff80082371e0 [verbose debug info unavailable]
<0>[ 11.618338] Internal error: Oops: 96000045 [#1] PREEMPT SMP
<4>[ 11.618381] Modules linked in:
<4>[ 11.618524] task: ffffffc0c6ec9180 task.stack: ffffffc0c6f40000
<4>[ 11.618569] PC is at __set_page_owner+0x48/0x78
<4>[ 11.618607] LR is at __set_page_owner+0x44/0x78
<4>[ 11.626025] [<ffffff80082371e0>] __set_page_owner+0x48/0x78
<4>[ 11.626071] [<ffffff80081df9f0>] get_page_from_freelist+0x880/0x8e8
<4>[ 11.626118] [<ffffff80081e00a4>] __alloc_pages_nodemask+0x14c/0xc48
<4>[ 11.626165] [<ffffff80081e610c>] __do_page_cache_readahead+0xdc/0x264
<4>[ 11.626214] [<ffffff80081d8824>] filemap_fault+0x2ac/0x550
<4>[ 11.626259] [<ffffff80082e5cf8>] ext4_filemap_fault+0x3c/0x58
<4>[ 11.626305] [<ffffff800820a2f8>] __do_fault+0x80/0x120
<4>[ 11.626347] [<ffffff800820eb4c>] handle_mm_fault+0x704/0xbb0
<4>[ 11.626393] [<ffffff800809ba70>] do_page_fault+0x2e8/0x394
<4>[ 11.626437] [<ffffff8008080be4>] do_mem_abort+0x88/0x124
Pre-4.7 kernels also need f86e427197 ("mm: check the return value of
lookup_page_ext for all call sites").
Link: http://lkml.kernel.org/r/20171107094131.14621-1-jaewon31.kim@samsung.com
Fixes: eefa864b701d ("mm/page_ext: resurrect struct page extending code for debugging")
Signed-off-by: Jaewon Kim <jaewon31.kim(a)samsung.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Joonsoo Kim <js1304(a)gmail.com>
Cc: <stable(a)vger.kernel.org> [depends on f86e427197, see above]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_ext.c | 4 ----
1 file changed, 4 deletions(-)
diff -puN mm/page_ext.c~mm-page_ext-check-if-page_ext-is-not-prepared mm/page_ext.c
--- a/mm/page_ext.c~mm-page_ext-check-if-page_ext-is-not-prepared
+++ a/mm/page_ext.c
@@ -125,7 +125,6 @@ struct page_ext *lookup_page_ext(struct
struct page_ext *base;
base = NODE_DATA(page_to_nid(page))->node_page_ext;
-#if defined(CONFIG_DEBUG_VM)
/*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -134,7 +133,6 @@ struct page_ext *lookup_page_ext(struct
*/
if (unlikely(!base))
return NULL;
-#endif
index = pfn - round_down(node_start_pfn(page_to_nid(page)),
MAX_ORDER_NR_PAGES);
return get_entry(base, index);
@@ -199,7 +197,6 @@ struct page_ext *lookup_page_ext(struct
{
unsigned long pfn = page_to_pfn(page);
struct mem_section *section = __pfn_to_section(pfn);
-#if defined(CONFIG_DEBUG_VM)
/*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -208,7 +205,6 @@ struct page_ext *lookup_page_ext(struct
*/
if (!section->page_ext)
return NULL;
-#endif
return get_entry(section->page_ext, pfn);
}
_
From: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Subject: mm/page_alloc.c: broken deferred calculation
In reset_deferred_meminit() we determine number of pages that must not be
deferred. We initialize pages for at least 2G of memory, but also pages
for reserved memory in this node.
The reserved memory is determined in this function:
memblock_reserved_memory_within(), which operates over physical addresses,
and returns size in bytes. However, reset_deferred_meminit() assumes that
that this function operates with pfns, and returns page count.
The result is that in the best case machine boots slower than expected due
to initializing more pages than needed in single thread, and in the worst
case panics because fewer than needed pages are initialized early.
Link: http://lkml.kernel.org/r/20171021011707.15191-1-pasha.tatashin@oracle.com
Fixes: 864b9a393dcb ("mm: consider memblock reservations for deferred memory initialization sizing")
Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/mmzone.h | 3 ++-
mm/page_alloc.c | 27 ++++++++++++++++++---------
2 files changed, 20 insertions(+), 10 deletions(-)
diff -puN include/linux/mmzone.h~mm-broken-deferred-calculation include/linux/mmzone.h
--- a/include/linux/mmzone.h~mm-broken-deferred-calculation
+++ a/include/linux/mmzone.h
@@ -700,7 +700,8 @@ typedef struct pglist_data {
* is the first PFN that needs to be initialised.
*/
unsigned long first_deferred_pfn;
- unsigned long static_init_size;
+ /* Number of non-deferred pages */
+ unsigned long static_init_pgcnt;
#endif /* CONFIG_DEFERRED_STRUCT_PAGE_INIT */
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
diff -puN mm/page_alloc.c~mm-broken-deferred-calculation mm/page_alloc.c
--- a/mm/page_alloc.c~mm-broken-deferred-calculation
+++ a/mm/page_alloc.c
@@ -291,28 +291,37 @@ EXPORT_SYMBOL(nr_online_nodes);
int page_group_by_mobility_disabled __read_mostly;
#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
+
+/*
+ * Determine how many pages need to be initialized durig early boot
+ * (non-deferred initialization).
+ * The value of first_deferred_pfn will be set later, once non-deferred pages
+ * are initialized, but for now set it ULONG_MAX.
+ */
static inline void reset_deferred_meminit(pg_data_t *pgdat)
{
- unsigned long max_initialise;
- unsigned long reserved_lowmem;
+ phys_addr_t start_addr, end_addr;
+ unsigned long max_pgcnt;
+ unsigned long reserved;
/*
* Initialise at least 2G of a node but also take into account that
* two large system hashes that can take up 1GB for 0.25TB/node.
*/
- max_initialise = max(2UL << (30 - PAGE_SHIFT),
- (pgdat->node_spanned_pages >> 8));
+ max_pgcnt = max(2UL << (30 - PAGE_SHIFT),
+ (pgdat->node_spanned_pages >> 8));
/*
* Compensate the all the memblock reservations (e.g. crash kernel)
* from the initial estimation to make sure we will initialize enough
* memory to boot.
*/
- reserved_lowmem = memblock_reserved_memory_within(pgdat->node_start_pfn,
- pgdat->node_start_pfn + max_initialise);
- max_initialise += reserved_lowmem;
+ start_addr = PFN_PHYS(pgdat->node_start_pfn);
+ end_addr = PFN_PHYS(pgdat->node_start_pfn + max_pgcnt);
+ reserved = memblock_reserved_memory_within(start_addr, end_addr);
+ max_pgcnt += PHYS_PFN(reserved);
- pgdat->static_init_size = min(max_initialise, pgdat->node_spanned_pages);
+ pgdat->static_init_pgcnt = min(max_pgcnt, pgdat->node_spanned_pages);
pgdat->first_deferred_pfn = ULONG_MAX;
}
@@ -339,7 +348,7 @@ static inline bool update_defer_init(pg_
if (zone_end < pgdat_end_pfn(pgdat))
return true;
(*nr_initialised)++;
- if ((*nr_initialised > pgdat->static_init_size) &&
+ if ((*nr_initialised > pgdat->static_init_pgcnt) &&
(pfn & (PAGES_PER_SECTION - 1)) == 0) {
pgdat->first_deferred_pfn = pfn;
return false;
_
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap: fix false error message in __swp_swapcount()
When a page fault occurs for a swap entry, the physical swap readahead
(not the VMA base swap readahead) may readahead several swap entries after
the fault swap entry. The readahead algorithm calculates some of the swap
entries to readahead via increasing the offset of the fault swap entry
without checking whether they are beyond the end of the swap device and it
relys on the __swp_swapcount() and swapcache_prepare() to check it.
Although __swp_swapcount() checks for the swap entry passed in, it will
complain with the error message as follow for the expected invalid swap
entry. This may make the end users confused.
swap_info_get: Bad swap offset entry 0200f8a7
To fix the false error message, the swap entry checking is added in
swapin_readahead() to avoid to pass the out-of-bound swap entries and the
swap entry reserved for the swap header to __swp_swapcount() and
swapcache_prepare().
Link: http://lkml.kernel.org/r/20171102054225.22897-1-ying.huang@intel.com
Fixes: e8c26ab60598 ("mm/swap: skip readahead for unreferenced swap slots")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Christian Kujau <lists(a)nerdbynature.de>
Acked-by: Minchan Kim <minchan(a)kernel.org>
Suggested-by: Minchan Kim <minchan(a)kernel.org>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/swap_state.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN mm/swap_state.c~mm-swap-fix-false-error-message-in-__swp_swapcount mm/swap_state.c
--- a/mm/swap_state.c~mm-swap-fix-false-error-message-in-__swp_swapcount
+++ a/mm/swap_state.c
@@ -559,6 +559,7 @@ struct page *swapin_readahead(swp_entry_
unsigned long offset = entry_offset;
unsigned long start_offset, end_offset;
unsigned long mask;
+ struct swap_info_struct *si = swp_swap_info(entry);
struct blk_plug plug;
bool do_poll = true, page_allocated;
@@ -572,6 +573,8 @@ struct page *swapin_readahead(swp_entry_
end_offset = offset | mask;
if (!start_offset) /* First page is swap header. */
start_offset++;
+ if (end_offset >= si->max)
+ end_offset = si->max - 1;
blk_start_plug(&plug);
for (offset = start_offset; offset <= end_offset ; offset++) {
_
From: alex chen <alex.chen(a)huawei.com>
Subject: ocfs2: should wait dio before inode lock in ocfs2_setattr()
we should wait dio requests to finish before inode lock in
ocfs2_setattr(), otherwise the following deadlock will happen:
process 1 process 2 process 3
truncate file 'A' end_io of writing file 'A' receiving the bast messages
ocfs2_setattr
ocfs2_inode_lock_tracker
ocfs2_inode_lock_full
inode_dio_wait
__inode_dio_wait
-->waiting for all dio
requests finish
dlm_proxy_ast_handler
dlm_do_local_bast
ocfs2_blocking_ast
ocfs2_generic_handle_bast
set OCFS2_LOCK_BLOCKED flag
dio_end_io
dio_bio_end_aio
dio_complete
ocfs2_dio_end_io
ocfs2_dio_end_io_write
ocfs2_inode_lock
__ocfs2_cluster_lock
ocfs2_wait_for_mask
-->waiting for OCFS2_LOCK_BLOCKED
flag to be cleared, that is waiting
for 'process 1' unlocking the inode lock
inode_dio_end
-->here dec the i_dio_count, but will never
be called, so a deadlock happened.
Link: http://lkml.kernel.org/r/59F81636.70508@huawei.com
Signed-off-by: Alex Chen <alex.chen(a)huawei.com>
Reviewed-by: Jun Piao <piaojun(a)huawei.com>
Reviewed-by: Joseph Qi <jiangqi903(a)gmail.com>
Acked-by: Changwei Ge <ge.changwei(a)h3c.com>
Cc: Mark Fasheh <mfasheh(a)versity.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/ocfs2/file.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff -puN fs/ocfs2/file.c~ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr fs/ocfs2/file.c
--- a/fs/ocfs2/file.c~ocfs2-should-wait-dio-before-inode-lock-in-ocfs2_setattr
+++ a/fs/ocfs2/file.c
@@ -1161,6 +1161,13 @@ int ocfs2_setattr(struct dentry *dentry,
}
size_change = S_ISREG(inode->i_mode) && attr->ia_valid & ATTR_SIZE;
if (size_change) {
+ /*
+ * Here we should wait dio to finish before inode lock
+ * to avoid a deadlock between ocfs2_setattr() and
+ * ocfs2_dio_end_io_write()
+ */
+ inode_dio_wait(inode);
+
status = ocfs2_rw_lock(inode, 1);
if (status < 0) {
mlog_errno(status);
@@ -1200,8 +1207,6 @@ int ocfs2_setattr(struct dentry *dentry,
if (status)
goto bail_unlock;
- inode_dio_wait(inode);
-
if (i_size_read(inode) >= attr->ia_size) {
if (ocfs2_should_order_data(inode)) {
status = ocfs2_begin_ordered_truncate(inode,
_
From: Changwei Ge <ge.changwei(a)h3c.com>
Subject: ocfs2: fix cluster hang after a node dies
When a node dies, other live nodes have to choose a new master for an
existed lock resource mastered by the dead node.
As for ocfs2/dlm implementation, this is done by function -
dlm_move_lockres_to_recovery_list which marks those lock rsources as
DLM_LOCK_RES_RECOVERING and manages them via a list from which DLM changes
lock resource's master later.
So without invoking dlm_move_lockres_to_recovery_list, no master will be
choosed after dlm recovery accomplishment since no lock resource can be
found through ::resource list.
What's worse is that if DLM_LOCK_RES_RECOVERING is not marked for lock
resources mastered a dead node, it will break up synchronization among
nodes.
So invoke dlm_move_lockres_to_recovery_list again.
Fixs: 'commit ee8f7fcbe638 ("ocfs2/dlm: continue to purge recovery lockres when recovery master goes down")'
Link: http://lkml.kernel.org/r/63ADC13FD55D6546B7DECE290D39E373CED6E0F9@H3CMLB14-…
Signed-off-by: Changwei Ge <ge.changwei(a)h3c.com>
Reported-by: Vitaly Mayatskih <v.mayatskih(a)gmail.com>
Tested-by: Vitaly Mayatskikh <v.mayatskih(a)gmail.com>
Cc: Mark Fasheh <mfasheh(a)versity.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: Junxiao Bi <junxiao.bi(a)oracle.com>
Cc: Joseph Qi <jiangqi903(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/ocfs2/dlm/dlmrecovery.c | 1 +
1 file changed, 1 insertion(+)
diff -puN fs/ocfs2/dlm/dlmrecovery.c~ocfs2-fix-cluster-hang-after-a-node-dies fs/ocfs2/dlm/dlmrecovery.c
--- a/fs/ocfs2/dlm/dlmrecovery.c~ocfs2-fix-cluster-hang-after-a-node-dies
+++ a/fs/ocfs2/dlm/dlmrecovery.c
@@ -2419,6 +2419,7 @@ static void dlm_do_local_recovery_cleanu
dlm_lockres_put(res);
continue;
}
+ dlm_move_lockres_to_recovery_list(dlm, res);
} else if (res->owner == dlm->node_num) {
dlm_free_dead_locks(dlm, res, dead_node);
__dlm_lockres_calc_usage(dlm, res);
_
Please can you queue up the following for stable:
df80cd9b28b9 sctp: do not peel off an assoc from one netns to another one
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
The patch titled
Subject: mm, swap: fix false error message in __swp_swapcount()
has been removed from the -mm tree. Its filename was
mm-swap-skip-swapcache-for-swapin-of-synchronous-device-fix.patch
This patch was dropped because it was folded into mm-swap-skip-swapcache-for-swapin-of-synchronous-device.patch
------------------------------------------------------
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap: fix false error message in __swp_swapcount()
When a page fault occurs for a swap entry, the physical swap readahead
(not the VMA base swap readahead) may readahead several swap entries after
the fault swap entry. The readahead algorithm calculates some of the swap
entries to readahead via increasing the offset of the fault swap entry
without checking whether they are beyond the end of the swap device and it
relys on the __swp_swapcount() and swapcache_prepare() to check it.
Although __swp_swapcount() checks for the swap entry passed in, it will
complain with the error message as follow for the expected invalid swap
entry. This may make the end users confused.
swap_info_get: Bad swap offset entry 0200f8a7
To fix the false error message, the swap entry checking is added in
swapin_readahead() to avoid to pass the out-of-bound swap entries and the
swap entry reserved for the swap header to __swp_swapcount() and
swapcache_prepare().
Link: http://lkml.kernel.org/r/20171102054225.22897-1-ying.huang@intel.com
Fixes: e8c26ab60598 ("mm/swap: skip readahead for unreferenced swap slots")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Christian Kujau <lists(a)nerdbynature.de>
Acked-by: Minchan Kim <minchan(a)kernel.org>
Suggested-by: Minchan Kim <minchan(a)kernel.org>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/swap_state.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN mm/swap_state.c~mm-swap-skip-swapcache-for-swapin-of-synchronous-device-fix mm/swap_state.c
--- a/mm/swap_state.c~mm-swap-skip-swapcache-for-swapin-of-synchronous-device-fix
+++ a/mm/swap_state.c
@@ -559,6 +559,7 @@ struct page *swapin_readahead(swp_entry_
unsigned long offset = entry_offset;
unsigned long start_offset, end_offset;
unsigned long mask;
+ struct swap_info_struct *si = swp_swap_info(entry);
struct blk_plug plug;
bool do_poll = true, page_allocated;
@@ -572,6 +573,8 @@ struct page *swapin_readahead(swp_entry_
end_offset = offset | mask;
if (!start_offset) /* First page is swap header. */
start_offset++;
+ if (end_offset >= si->max)
+ end_offset = si->max - 1;
blk_start_plug(&plug);
for (offset = start_offset; offset <= end_offset ; offset++) {
_
Patches currently in -mm which might be from huang.ying.caritas(a)gmail.com are
mm-swap-skip-swapcache-for-swapin-of-synchronous-device.patch
The default max_cache_size_bytes for dm-bufio is meant to be the lesser
of 25% of the size of the vmalloc area and 2% of the size of lowmem.
However, on 32-bit systems the intermediate result in the expression
(VMALLOC_END - VMALLOC_START) * DM_BUFIO_VMALLOC_PERCENT / 100
overflows, causing the wrong result to be computed. For example, on a
32-bit system where the vmalloc area is 520093696 bytes, the result is
1174405 rather than the expected 130023424, which makes the maximum
cache size much too small (far less than 2% of lowmem). This causes
severe performance problems for dm-verity users on affected systems.
Fix this by using mult_frac() to correctly multiply by a percentage. Do
this for all places in dm-bufio that multiply by a percentage. Also
replace (VMALLOC_END - VMALLOC_START) with VMALLOC_TOTAL, which contrary
to the comment is now defined in include/linux/vmalloc.h.
Fixes: 95d402f057f2 ("dm: add bufio")
Cc: <stable(a)vger.kernel.org> # v3.2+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
drivers/md/dm-bufio.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index 33bb074d6941..b8ac591aaaa7 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -974,7 +974,8 @@ static void __get_memory_limit(struct dm_bufio_client *c,
buffers = c->minimum_buffers;
*limit_buffers = buffers;
- *threshold_buffers = buffers * DM_BUFIO_WRITEBACK_PERCENT / 100;
+ *threshold_buffers = mult_frac(buffers,
+ DM_BUFIO_WRITEBACK_PERCENT, 100);
}
/*
@@ -1910,19 +1911,15 @@ static int __init dm_bufio_init(void)
memset(&dm_bufio_caches, 0, sizeof dm_bufio_caches);
memset(&dm_bufio_cache_names, 0, sizeof dm_bufio_cache_names);
- mem = (__u64)((totalram_pages - totalhigh_pages) *
- DM_BUFIO_MEMORY_PERCENT / 100) << PAGE_SHIFT;
+ mem = (__u64)mult_frac(totalram_pages - totalhigh_pages,
+ DM_BUFIO_MEMORY_PERCENT, 100) << PAGE_SHIFT;
if (mem > ULONG_MAX)
mem = ULONG_MAX;
#ifdef CONFIG_MMU
- /*
- * Get the size of vmalloc space the same way as VMALLOC_TOTAL
- * in fs/proc/internal.h
- */
- if (mem > (VMALLOC_END - VMALLOC_START) * DM_BUFIO_VMALLOC_PERCENT / 100)
- mem = (VMALLOC_END - VMALLOC_START) * DM_BUFIO_VMALLOC_PERCENT / 100;
+ if (mem > mult_frac(VMALLOC_TOTAL, DM_BUFIO_VMALLOC_PERCENT, 100))
+ mem = mult_frac(VMALLOC_TOTAL, DM_BUFIO_VMALLOC_PERCENT, 100);
#endif
dm_bufio_default_cache_size = mem;
--
2.15.0.448.gf294e3d99a-goog
From: Ian Abbott <abbotti(a)mev.co.uk>
Both fpga_region_get_manager() and fpga_region_get_bridges() call
of_parse_phandle(), but nothing calls of_node_put() on the returned
struct device_node pointers. Make sure to do that to stop their
reference counters getting out of whack.
Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA")
Cc: <stable(a)vger.kernel.org> # 4.10+
Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Alan Tull <atull(a)kernel.org>
---
drivers/fpga/of-fpga-region.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
index a0c13cb..7dfaa95 100644
--- a/drivers/fpga/of-fpga-region.c
+++ b/drivers/fpga/of-fpga-region.c
@@ -73,6 +73,7 @@ static struct fpga_manager *of_fpga_region_get_mgr(struct device_node *np)
mgr_node = of_parse_phandle(np, "fpga-mgr", 0);
if (mgr_node) {
mgr = of_fpga_mgr_get(mgr_node);
+ of_node_put(mgr_node);
of_node_put(np);
return mgr;
}
@@ -120,10 +121,13 @@ static int of_fpga_region_get_bridges(struct fpga_region *region)
parent_br = region_np->parent;
/* If overlay has a list of bridges, use it. */
- if (of_parse_phandle(info->overlay, "fpga-bridges", 0))
+ br = of_parse_phandle(info->overlay, "fpga-bridges", 0);
+ if (br) {
+ of_node_put(br);
np = info->overlay;
- else
+ } else {
np = region_np;
+ }
for (i = 0; ; i++) {
br = of_parse_phandle(np, "fpga-bridges", i);
@@ -131,12 +135,15 @@ static int of_fpga_region_get_bridges(struct fpga_region *region)
break;
/* If parent bridge is in list, skip it. */
- if (br == parent_br)
+ if (br == parent_br) {
+ of_node_put(br);
continue;
+ }
/* If node is a bridge, get it and add to list */
ret = of_fpga_bridge_get_to_list(br, info,
®ion->bridge_list);
+ of_node_put(br);
/* If any of the bridges are in use, give up */
if (ret == -EBUSY) {
--
2.7.4
This is a note to let you know that I've just added the patch titled
EDAC, sb_edac: Don't create a second memory controller if HA1 is not present
to the 4.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
edac-sb_edac-don-t-create-a-second-memory-controller-if-ha1-is-not-present.patch
and it can be found in the queue-4.13 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 15cc3ae001873845b5d842e212478a6570c7d938 Mon Sep 17 00:00:00 2001
From: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Date: Wed, 13 Sep 2017 18:42:14 +0800
Subject: EDAC, sb_edac: Don't create a second memory controller if HA1 is not present
From: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
commit 15cc3ae001873845b5d842e212478a6570c7d938 upstream.
Yi Zhang reported the following failure on a 2-socket Haswell (E5-2603v3)
server (DELL PowerEdge 730xd):
EDAC sbridge: Some needed devices are missing
EDAC MC: Removed device 0 for sb_edac.c Haswell SrcID#0_Ha#0: DEV 0000:7f:12.0
EDAC MC: Removed device 1 for sb_edac.c Haswell SrcID#1_Ha#0: DEV 0000:ff:12.0
EDAC sbridge: Couldn't find mci handler
EDAC sbridge: Couldn't find mci handler
EDAC sbridge: Failed to register device with error -19.
The refactored sb_edac driver creates the IMC1 (the 2nd memory
controller) if any IMC1 device is present. In this case only
HA1_TA of IMC1 was present, but the driver expected to find
HA1/HA1_TM/HA1_TAD[0-3] devices too, leading to the above failure.
The document [1] says the 'E5-2603 v3' CPU has 4 memory channels max. Yi
Zhang inserted one DIMM per channel for each CPU, and did random error
address injection test with this patch:
4024 addresses fell in TOLM hole area
12715 addresses fell in CPU_SrcID#0_Ha#0_Chan#0_DIMM#0
12774 addresses fell in CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
12798 addresses fell in CPU_SrcID#0_Ha#0_Chan#2_DIMM#0
12913 addresses fell in CPU_SrcID#0_Ha#0_Chan#3_DIMM#0
12674 addresses fell in CPU_SrcID#1_Ha#0_Chan#0_DIMM#0
12686 addresses fell in CPU_SrcID#1_Ha#0_Chan#1_DIMM#0
12882 addresses fell in CPU_SrcID#1_Ha#0_Chan#2_DIMM#0
12934 addresses fell in CPU_SrcID#1_Ha#0_Chan#3_DIMM#0
106400 addresses were injected totally.
The test result shows that all the 4 channels belong to IMC0 per CPU, so
the server really only has one IMC per CPU.
In the 1st page of chapter 2 in datasheet [2], it also says 'E5-2600 v3'
implements either one or two IMCs. For CPUs with one IMC, IMC1 is not
used and should be ignored.
Thus, do not create a second memory controller if the key HA1 is absent.
[1] http://ark.intel.com/products/83349/Intel-Xeon-Processor-E5-2603-v3-15M-Cac…
[2] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeo…
Reported-and-tested-by: Yi Zhang <yizhan(a)redhat.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/20170913104214.7325-1-qiuxu.zhuo@intel.com
[ Massage commit message. ]
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/sb_edac.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -455,6 +455,7 @@ static const struct pci_id_table pci_dev
static const struct pci_id_descr pci_dev_descr_ibridge[] = {
/* Processor Home Agent */
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0, 0, IMC0) },
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1, 1, IMC1) },
/* Memory controller */
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA, 0, IMC0) },
@@ -465,7 +466,6 @@ static const struct pci_id_descr pci_dev
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TAD3, 0, IMC0) },
/* Optional, mode 2HA */
- { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1, 1, IMC1) },
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TA, 1, IMC1) },
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_RAS, 1, IMC1) },
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TAD0, 1, IMC1) },
@@ -2260,6 +2260,13 @@ static int sbridge_get_onedevice(struct
next_imc:
sbridge_dev = get_sbridge_dev(bus, dev_descr->dom, multi_bus, sbridge_dev);
if (!sbridge_dev) {
+ /* If the HA1 wasn't found, don't create EDAC second memory controller */
+ if (dev_descr->dom == IMC1 && devno != 1) {
+ edac_dbg(0, "Skip IMC1: %04x:%04x (since HA1 was absent)\n",
+ PCI_VENDOR_ID_INTEL, dev_descr->dev_id);
+ pci_dev_put(pdev);
+ return 0;
+ }
if (dev_descr->dom == SOCK)
goto out_imc;
Patches currently in stable-queue which might be from qiuxu.zhuo(a)intel.com are
queue-4.13/edac-sb_edac-don-t-create-a-second-memory-controller-if-ha1-is-not-present.patch
This is a note to let you know that I've just added the patch titled
EDAC, sb_edac: Don't create a second memory controller if HA1 is not present
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
edac-sb_edac-don-t-create-a-second-memory-controller-if-ha1-is-not-present.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 15cc3ae001873845b5d842e212478a6570c7d938 Mon Sep 17 00:00:00 2001
From: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Date: Wed, 13 Sep 2017 18:42:14 +0800
Subject: EDAC, sb_edac: Don't create a second memory controller if HA1 is not present
From: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
commit 15cc3ae001873845b5d842e212478a6570c7d938 upstream.
Yi Zhang reported the following failure on a 2-socket Haswell (E5-2603v3)
server (DELL PowerEdge 730xd):
EDAC sbridge: Some needed devices are missing
EDAC MC: Removed device 0 for sb_edac.c Haswell SrcID#0_Ha#0: DEV 0000:7f:12.0
EDAC MC: Removed device 1 for sb_edac.c Haswell SrcID#1_Ha#0: DEV 0000:ff:12.0
EDAC sbridge: Couldn't find mci handler
EDAC sbridge: Couldn't find mci handler
EDAC sbridge: Failed to register device with error -19.
The refactored sb_edac driver creates the IMC1 (the 2nd memory
controller) if any IMC1 device is present. In this case only
HA1_TA of IMC1 was present, but the driver expected to find
HA1/HA1_TM/HA1_TAD[0-3] devices too, leading to the above failure.
The document [1] says the 'E5-2603 v3' CPU has 4 memory channels max. Yi
Zhang inserted one DIMM per channel for each CPU, and did random error
address injection test with this patch:
4024 addresses fell in TOLM hole area
12715 addresses fell in CPU_SrcID#0_Ha#0_Chan#0_DIMM#0
12774 addresses fell in CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
12798 addresses fell in CPU_SrcID#0_Ha#0_Chan#2_DIMM#0
12913 addresses fell in CPU_SrcID#0_Ha#0_Chan#3_DIMM#0
12674 addresses fell in CPU_SrcID#1_Ha#0_Chan#0_DIMM#0
12686 addresses fell in CPU_SrcID#1_Ha#0_Chan#1_DIMM#0
12882 addresses fell in CPU_SrcID#1_Ha#0_Chan#2_DIMM#0
12934 addresses fell in CPU_SrcID#1_Ha#0_Chan#3_DIMM#0
106400 addresses were injected totally.
The test result shows that all the 4 channels belong to IMC0 per CPU, so
the server really only has one IMC per CPU.
In the 1st page of chapter 2 in datasheet [2], it also says 'E5-2600 v3'
implements either one or two IMCs. For CPUs with one IMC, IMC1 is not
used and should be ignored.
Thus, do not create a second memory controller if the key HA1 is absent.
[1] http://ark.intel.com/products/83349/Intel-Xeon-Processor-E5-2603-v3-15M-Cac…
[2] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeo…
Reported-and-tested-by: Yi Zhang <yizhan(a)redhat.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Link: http://lkml.kernel.org/r/20170913104214.7325-1-qiuxu.zhuo@intel.com
[ Massage commit message. ]
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/sb_edac.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -462,6 +462,7 @@ static const struct pci_id_table pci_dev
static const struct pci_id_descr pci_dev_descr_ibridge[] = {
/* Processor Home Agent */
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0, 0, IMC0) },
+ { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1, 1, IMC1) },
/* Memory controller */
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TA, 0, IMC0) },
@@ -472,7 +473,6 @@ static const struct pci_id_descr pci_dev
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA0_TAD3, 0, IMC0) },
/* Optional, mode 2HA */
- { PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1, 1, IMC1) },
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TA, 1, IMC1) },
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_RAS, 1, IMC1) },
{ PCI_DESCR(PCI_DEVICE_ID_INTEL_IBRIDGE_IMC_HA1_TAD0, 1, IMC1) },
@@ -2291,6 +2291,13 @@ static int sbridge_get_onedevice(struct
next_imc:
sbridge_dev = get_sbridge_dev(bus, dev_descr->dom, multi_bus, sbridge_dev);
if (!sbridge_dev) {
+ /* If the HA1 wasn't found, don't create EDAC second memory controller */
+ if (dev_descr->dom == IMC1 && devno != 1) {
+ edac_dbg(0, "Skip IMC1: %04x:%04x (since HA1 was absent)\n",
+ PCI_VENDOR_ID_INTEL, dev_descr->dev_id);
+ pci_dev_put(pdev);
+ return 0;
+ }
if (dev_descr->dom == SOCK)
goto out_imc;
Patches currently in stable-queue which might be from qiuxu.zhuo(a)intel.com are
queue-4.14/edac-sb_edac-don-t-create-a-second-memory-controller-if-ha1-is-not-present.patch
This is a note to let you know that I've just added the patch titled
usb: usbtest: fix NULL pointer dereference
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-usbtest-fix-null-pointer-dereference.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7c80f9e4a588f1925b07134bb2e3689335f6c6d8 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Fri, 29 Sep 2017 10:54:24 -0400
Subject: usb: usbtest: fix NULL pointer dereference
From: Alan Stern <stern(a)rowland.harvard.edu>
commit 7c80f9e4a588f1925b07134bb2e3689335f6c6d8 upstream.
If the usbtest driver encounters a device with an IN bulk endpoint but
no OUT bulk endpoint, it will try to dereference a NULL pointer
(out->desc.bEndpointAddress). The problem can be solved by adding a
missing test.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/misc/usbtest.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -209,12 +209,13 @@ found:
return tmp;
}
- if (in) {
+ if (in)
dev->in_pipe = usb_rcvbulkpipe(udev,
in->desc.bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
+ if (out)
dev->out_pipe = usb_sndbulkpipe(udev,
out->desc.bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
- }
+
if (iso_in) {
dev->iso_in = &iso_in->desc;
dev->in_iso_pipe = usb_rcvisocpipe(udev,
Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are
queue-4.9/usb-usbtest-fix-null-pointer-dereference.patch
This is a note to let you know that I've just added the patch titled
mac80211: use constant time comparison with keys
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-use-constant-time-comparison-with-keys.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2bdd713b92a9cade239d3c7d15205a09f556624d Mon Sep 17 00:00:00 2001
From: "Jason A. Donenfeld" <Jason(a)zx2c4.com>
Date: Tue, 17 Oct 2017 20:32:07 +0200
Subject: mac80211: use constant time comparison with keys
From: Jason A. Donenfeld <Jason(a)zx2c4.com>
commit 2bdd713b92a9cade239d3c7d15205a09f556624d upstream.
Otherwise we risk leaking information via timing side channel.
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/key.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -19,6 +19,7 @@
#include <linux/slab.h>
#include <linux/export.h>
#include <net/mac80211.h>
+#include <crypto/algapi.h>
#include <asm/unaligned.h>
#include "ieee80211_i.h"
#include "driver-ops.h"
@@ -634,7 +635,7 @@ int ieee80211_key_link(struct ieee80211_
* new version of the key to avoid nonce reuse or replay issues.
*/
if (old_key && key->conf.keylen == old_key->conf.keylen &&
- !memcmp(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+ !crypto_memneq(key->conf.key, old_key->conf.key, key->conf.keylen)) {
ieee80211_key_free_unused(key);
ret = 0;
goto out;
Patches currently in stable-queue which might be from Jason(a)zx2c4.com are
queue-4.9/mac80211-use-constant-time-comparison-with-keys.patch
queue-4.9/netlink-do-not-set-cb_running-if-dump-s-start-errs.patch
This is a note to let you know that I've just added the patch titled
mac80211: don't compare TKIP TX MIC key in reinstall prevention
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cfbb0d90a7abb289edc91833d0905931f8805f12 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Tue, 24 Oct 2017 21:12:13 +0200
Subject: mac80211: don't compare TKIP TX MIC key in reinstall prevention
From: Johannes Berg <johannes.berg(a)intel.com>
commit cfbb0d90a7abb289edc91833d0905931f8805f12 upstream.
For the reinstall prevention, the code I had added compares the
whole key. It turns out though that iwlwifi firmware doesn't
provide the TKIP TX MIC key as it's not needed in client mode,
and thus the comparison will always return false.
For client mode, thus always zero out the TX MIC key part before
doing the comparison in order to avoid accepting the reinstall
of the key with identical encryption and RX MIC key, but not the
same TX MIC key (since the supplicant provides the real one.)
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/key.c | 36 ++++++++++++++++++++++++++++++++++--
1 file changed, 34 insertions(+), 2 deletions(-)
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -609,6 +609,39 @@ void ieee80211_key_free_unused(struct ie
ieee80211_key_free_common(key);
}
+static bool ieee80211_key_identical(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_key *old,
+ struct ieee80211_key *new)
+{
+ u8 tkip_old[WLAN_KEY_LEN_TKIP], tkip_new[WLAN_KEY_LEN_TKIP];
+ u8 *tk_old, *tk_new;
+
+ if (!old || new->conf.keylen != old->conf.keylen)
+ return false;
+
+ tk_old = old->conf.key;
+ tk_new = new->conf.key;
+
+ /*
+ * In station mode, don't compare the TX MIC key, as it's never used
+ * and offloaded rekeying may not care to send it to the host. This
+ * is the case in iwlwifi, for example.
+ */
+ if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+ new->conf.cipher == WLAN_CIPHER_SUITE_TKIP &&
+ new->conf.keylen == WLAN_KEY_LEN_TKIP &&
+ !(new->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE)) {
+ memcpy(tkip_old, tk_old, WLAN_KEY_LEN_TKIP);
+ memcpy(tkip_new, tk_new, WLAN_KEY_LEN_TKIP);
+ memset(tkip_old + NL80211_TKIP_DATA_OFFSET_TX_MIC_KEY, 0, 8);
+ memset(tkip_new + NL80211_TKIP_DATA_OFFSET_TX_MIC_KEY, 0, 8);
+ tk_old = tkip_old;
+ tk_new = tkip_new;
+ }
+
+ return !crypto_memneq(tk_old, tk_new, new->conf.keylen);
+}
+
int ieee80211_key_link(struct ieee80211_key *key,
struct ieee80211_sub_if_data *sdata,
struct sta_info *sta)
@@ -634,8 +667,7 @@ int ieee80211_key_link(struct ieee80211_
* Silently accept key re-installation without really installing the
* new version of the key to avoid nonce reuse or replay issues.
*/
- if (old_key && key->conf.keylen == old_key->conf.keylen &&
- !crypto_memneq(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+ if (ieee80211_key_identical(sdata, old_key, key)) {
ieee80211_key_free_unused(key);
ret = 0;
goto out;
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.9/mac80211-use-constant-time-comparison-with-keys.patch
queue-4.9/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-4.9/mac80211-accept-key-reinstall-without-changing-anything.patch
This is a note to let you know that I've just added the patch titled
mac80211: accept key reinstall without changing anything
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-accept-key-reinstall-without-changing-anything.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fdf7cb4185b60c68e1a75e61691c4afdc15dea0e Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Tue, 5 Sep 2017 14:54:54 +0200
Subject: mac80211: accept key reinstall without changing anything
From: Johannes Berg <johannes.berg(a)intel.com>
commit fdf7cb4185b60c68e1a75e61691c4afdc15dea0e upstream.
When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".
In particular, CVE-2017-13080 applies to GTK rekeying that
happened in firmware while the host is in D3, with the second
part of the attack being done after the host wakes up. In
this case, the wpa_supplicant mitigation isn't sufficient
since wpa_supplicant doesn't know the GTK material.
In case this happens, simply silently accept the new key
coming from userspace but don't take any action on it since
it's the same key; this keeps the PN replay counters intact.
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/key.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -4,7 +4,7 @@
* Copyright 2006-2007 Jiri Benc <jbenc(a)suse.cz>
* Copyright 2007-2008 Johannes Berg <johannes(a)sipsolutions.net>
* Copyright 2013-2014 Intel Mobile Communications GmbH
- * Copyright 2015 Intel Deutschland GmbH
+ * Copyright 2015-2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -619,9 +619,6 @@ int ieee80211_key_link(struct ieee80211_
pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
idx = key->conf.keyidx;
- key->local = sdata->local;
- key->sdata = sdata;
- key->sta = sta;
mutex_lock(&sdata->local->key_mtx);
@@ -632,6 +629,21 @@ int ieee80211_key_link(struct ieee80211_
else
old_key = key_mtx_dereference(sdata->local, sdata->keys[idx]);
+ /*
+ * Silently accept key re-installation without really installing the
+ * new version of the key to avoid nonce reuse or replay issues.
+ */
+ if (old_key && key->conf.keylen == old_key->conf.keylen &&
+ !memcmp(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+ ieee80211_key_free_unused(key);
+ ret = 0;
+ goto out;
+ }
+
+ key->local = sdata->local;
+ key->sdata = sdata;
+ key->sta = sta;
+
increment_tailroom_need_count(sdata);
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
@@ -647,6 +659,7 @@ int ieee80211_key_link(struct ieee80211_
ret = 0;
}
+ out:
mutex_unlock(&sdata->local->key_mtx);
return ret;
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.9/mac80211-use-constant-time-comparison-with-keys.patch
queue-4.9/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-4.9/mac80211-accept-key-reinstall-without-changing-anything.patch
On Tue, Nov 14, 2017 at 10:21:54PM -0800, Ivan Babrou wrote:
> Yep, looks like the patch fixed the issue for us:
Good.
Btw, please do not top-post.
> Logging still seems a bit verbose.
Those seeking msgs are KERN_DEBUG. You could set your printk level to
something sensible like info or so.
> Can you ask to backport the patch to 4.14?
Sure.
Greg, can you please queue
15cc3ae00187 ("EDAC, sb_edac: Don't create a second memory controller if HA1 is not present")
for 4.14-stable as it fixes loading sb_edac on Ivan's box?
Patch applies cleanly on 4.14.
Thanks!
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
This is a note to let you know that I've just added the patch titled
Input: ims-psu - check if CDC union descriptor is sane
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ea04efee7635c9120d015dcdeeeb6988130cb67a Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Date: Sat, 7 Oct 2017 11:07:47 -0700
Subject: Input: ims-psu - check if CDC union descriptor is sane
From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
commit ea04efee7635c9120d015dcdeeeb6988130cb67a upstream.
Before trying to use CDC union descriptor, try to validate whether that it
is sane by checking that intf->altsetting->extra is big enough and that
descriptor bLength is not too big and not too small.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/misc/ims-pcu.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -1635,13 +1635,25 @@ ims_pcu_get_cdc_union_desc(struct usb_in
return NULL;
}
- while (buflen > 0) {
+ while (buflen >= sizeof(*union_desc)) {
union_desc = (struct usb_cdc_union_desc *)buf;
+ if (union_desc->bLength > buflen) {
+ dev_err(&intf->dev, "Too large descriptor\n");
+ return NULL;
+ }
+
if (union_desc->bDescriptorType == USB_DT_CS_INTERFACE &&
union_desc->bDescriptorSubType == USB_CDC_UNION_TYPE) {
dev_dbg(&intf->dev, "Found union header\n");
- return union_desc;
+
+ if (union_desc->bLength >= sizeof(*union_desc))
+ return union_desc;
+
+ dev_err(&intf->dev,
+ "Union descriptor to short (%d vs %zd\n)",
+ union_desc->bLength, sizeof(*union_desc));
+ return NULL;
}
buflen -= union_desc->bLength;
Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are
queue-4.9/input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
This is a note to let you know that I've just added the patch titled
ALSA: seq: Cancel pending autoload work at unbinding device
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-seq-cancel-pending-autoload-work-at-unbinding-device.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fc27fe7e8deef2f37cba3f2be2d52b6ca5eb9d57 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 12 Sep 2017 12:41:20 +0200
Subject: ALSA: seq: Cancel pending autoload work at unbinding device
From: Takashi Iwai <tiwai(a)suse.de>
commit fc27fe7e8deef2f37cba3f2be2d52b6ca5eb9d57 upstream.
ALSA sequencer core has a mechanism to load the enumerated devices
automatically, and it's performed in an off-load work. This seems
causing some race when a sequencer is removed while the pending
autoload work is running. As syzkaller spotted, it may lead to some
use-after-free:
BUG: KASAN: use-after-free in snd_rawmidi_dev_seq_free+0x69/0x70
sound/core/rawmidi.c:1617
Write of size 8 at addr ffff88006c611d90 by task kworker/2:1/567
CPU: 2 PID: 567 Comm: kworker/2:1 Not tainted 4.13.0+ #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events autoload_drivers
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x192/0x22c lib/dump_stack.c:52
print_address_description+0x78/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x230/0x340 mm/kasan/report.c:409
__asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
snd_rawmidi_dev_seq_free+0x69/0x70 sound/core/rawmidi.c:1617
snd_seq_dev_release+0x4f/0x70 sound/core/seq_device.c:192
device_release+0x13f/0x210 drivers/base/core.c:814
kobject_cleanup lib/kobject.c:648 [inline]
kobject_release lib/kobject.c:677 [inline]
kref_put include/linux/kref.h:70 [inline]
kobject_put+0x145/0x240 lib/kobject.c:694
put_device+0x25/0x30 drivers/base/core.c:1799
klist_devices_put+0x36/0x40 drivers/base/bus.c:827
klist_next+0x264/0x4a0 lib/klist.c:403
next_device drivers/base/bus.c:270 [inline]
bus_for_each_dev+0x17e/0x210 drivers/base/bus.c:312
autoload_drivers+0x3b/0x50 sound/core/seq_device.c:117
process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
kthread+0x324/0x3f0 kernel/kthread.c:231
ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
The fix is simply to assure canceling the autoload work at removing
the device.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/seq/seq_device.c | 3 +++
1 file changed, 3 insertions(+)
--- a/sound/core/seq/seq_device.c
+++ b/sound/core/seq/seq_device.c
@@ -148,8 +148,10 @@ void snd_seq_device_load_drivers(void)
flush_work(&autoload_work);
}
EXPORT_SYMBOL(snd_seq_device_load_drivers);
+#define cancel_autoload_drivers() cancel_work_sync(&autoload_work)
#else
#define queue_autoload_drivers() /* NOP */
+#define cancel_autoload_drivers() /* NOP */
#endif
/*
@@ -159,6 +161,7 @@ static int snd_seq_device_dev_free(struc
{
struct snd_seq_device *dev = device->device_data;
+ cancel_autoload_drivers();
put_device(&dev->dev);
return 0;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.9/alsa-seq-cancel-pending-autoload-work-at-unbinding-device.patch
This is a note to let you know that I've just added the patch titled
usb: usbtest: fix NULL pointer dereference
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-usbtest-fix-null-pointer-dereference.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7c80f9e4a588f1925b07134bb2e3689335f6c6d8 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Fri, 29 Sep 2017 10:54:24 -0400
Subject: usb: usbtest: fix NULL pointer dereference
From: Alan Stern <stern(a)rowland.harvard.edu>
commit 7c80f9e4a588f1925b07134bb2e3689335f6c6d8 upstream.
If the usbtest driver encounters a device with an IN bulk endpoint but
no OUT bulk endpoint, it will try to dereference a NULL pointer
(out->desc.bEndpointAddress). The problem can be solved by adding a
missing test.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/misc/usbtest.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -185,12 +185,13 @@ found:
return tmp;
}
- if (in) {
+ if (in)
dev->in_pipe = usb_rcvbulkpipe(udev,
in->desc.bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
+ if (out)
dev->out_pipe = usb_sndbulkpipe(udev,
out->desc.bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
- }
+
if (iso_in) {
dev->iso_in = &iso_in->desc;
dev->in_iso_pipe = usb_rcvisocpipe(udev,
Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are
queue-4.4/usb-usbtest-fix-null-pointer-dereference.patch
This is a note to let you know that I've just added the patch titled
mac80211: use constant time comparison with keys
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-use-constant-time-comparison-with-keys.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2bdd713b92a9cade239d3c7d15205a09f556624d Mon Sep 17 00:00:00 2001
From: "Jason A. Donenfeld" <Jason(a)zx2c4.com>
Date: Tue, 17 Oct 2017 20:32:07 +0200
Subject: mac80211: use constant time comparison with keys
From: Jason A. Donenfeld <Jason(a)zx2c4.com>
commit 2bdd713b92a9cade239d3c7d15205a09f556624d upstream.
Otherwise we risk leaking information via timing side channel.
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/key.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -19,6 +19,7 @@
#include <linux/slab.h>
#include <linux/export.h>
#include <net/mac80211.h>
+#include <crypto/algapi.h>
#include <asm/unaligned.h>
#include "ieee80211_i.h"
#include "driver-ops.h"
@@ -633,7 +634,7 @@ int ieee80211_key_link(struct ieee80211_
* new version of the key to avoid nonce reuse or replay issues.
*/
if (old_key && key->conf.keylen == old_key->conf.keylen &&
- !memcmp(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+ !crypto_memneq(key->conf.key, old_key->conf.key, key->conf.keylen)) {
ieee80211_key_free_unused(key);
ret = 0;
goto out;
Patches currently in stable-queue which might be from Jason(a)zx2c4.com are
queue-4.4/mac80211-use-constant-time-comparison-with-keys.patch
This is a note to let you know that I've just added the patch titled
mac80211: don't compare TKIP TX MIC key in reinstall prevention
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cfbb0d90a7abb289edc91833d0905931f8805f12 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Tue, 24 Oct 2017 21:12:13 +0200
Subject: mac80211: don't compare TKIP TX MIC key in reinstall prevention
From: Johannes Berg <johannes.berg(a)intel.com>
commit cfbb0d90a7abb289edc91833d0905931f8805f12 upstream.
For the reinstall prevention, the code I had added compares the
whole key. It turns out though that iwlwifi firmware doesn't
provide the TKIP TX MIC key as it's not needed in client mode,
and thus the comparison will always return false.
For client mode, thus always zero out the TX MIC key part before
doing the comparison in order to avoid accepting the reinstall
of the key with identical encryption and RX MIC key, but not the
same TX MIC key (since the supplicant provides the real one.)
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/key.c | 36 ++++++++++++++++++++++++++++++++++--
1 file changed, 34 insertions(+), 2 deletions(-)
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -608,6 +608,39 @@ void ieee80211_key_free_unused(struct ie
ieee80211_key_free_common(key);
}
+static bool ieee80211_key_identical(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_key *old,
+ struct ieee80211_key *new)
+{
+ u8 tkip_old[WLAN_KEY_LEN_TKIP], tkip_new[WLAN_KEY_LEN_TKIP];
+ u8 *tk_old, *tk_new;
+
+ if (!old || new->conf.keylen != old->conf.keylen)
+ return false;
+
+ tk_old = old->conf.key;
+ tk_new = new->conf.key;
+
+ /*
+ * In station mode, don't compare the TX MIC key, as it's never used
+ * and offloaded rekeying may not care to send it to the host. This
+ * is the case in iwlwifi, for example.
+ */
+ if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+ new->conf.cipher == WLAN_CIPHER_SUITE_TKIP &&
+ new->conf.keylen == WLAN_KEY_LEN_TKIP &&
+ !(new->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE)) {
+ memcpy(tkip_old, tk_old, WLAN_KEY_LEN_TKIP);
+ memcpy(tkip_new, tk_new, WLAN_KEY_LEN_TKIP);
+ memset(tkip_old + NL80211_TKIP_DATA_OFFSET_TX_MIC_KEY, 0, 8);
+ memset(tkip_new + NL80211_TKIP_DATA_OFFSET_TX_MIC_KEY, 0, 8);
+ tk_old = tkip_old;
+ tk_new = tkip_new;
+ }
+
+ return !crypto_memneq(tk_old, tk_new, new->conf.keylen);
+}
+
int ieee80211_key_link(struct ieee80211_key *key,
struct ieee80211_sub_if_data *sdata,
struct sta_info *sta)
@@ -633,8 +666,7 @@ int ieee80211_key_link(struct ieee80211_
* Silently accept key re-installation without really installing the
* new version of the key to avoid nonce reuse or replay issues.
*/
- if (old_key && key->conf.keylen == old_key->conf.keylen &&
- !crypto_memneq(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+ if (ieee80211_key_identical(sdata, old_key, key)) {
ieee80211_key_free_unused(key);
ret = 0;
goto out;
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.4/mac80211-use-constant-time-comparison-with-keys.patch
queue-4.4/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-4.4/mac80211-accept-key-reinstall-without-changing-anything.patch
This is a note to let you know that I've just added the patch titled
mac80211: accept key reinstall without changing anything
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-accept-key-reinstall-without-changing-anything.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fdf7cb4185b60c68e1a75e61691c4afdc15dea0e Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Tue, 5 Sep 2017 14:54:54 +0200
Subject: mac80211: accept key reinstall without changing anything
From: Johannes Berg <johannes.berg(a)intel.com>
commit fdf7cb4185b60c68e1a75e61691c4afdc15dea0e upstream.
When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".
In particular, CVE-2017-13080 applies to GTK rekeying that
happened in firmware while the host is in D3, with the second
part of the attack being done after the host wakes up. In
this case, the wpa_supplicant mitigation isn't sufficient
since wpa_supplicant doesn't know the GTK material.
In case this happens, simply silently accept the new key
coming from userspace but don't take any action on it since
it's the same key; this keeps the PN replay counters intact.
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/key.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -4,6 +4,7 @@
* Copyright 2006-2007 Jiri Benc <jbenc(a)suse.cz>
* Copyright 2007-2008 Johannes Berg <johannes(a)sipsolutions.net>
* Copyright 2013-2014 Intel Mobile Communications GmbH
+ * Copyright 2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -617,9 +618,6 @@ int ieee80211_key_link(struct ieee80211_
pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
idx = key->conf.keyidx;
- key->local = sdata->local;
- key->sdata = sdata;
- key->sta = sta;
mutex_lock(&sdata->local->key_mtx);
@@ -630,6 +628,21 @@ int ieee80211_key_link(struct ieee80211_
else
old_key = key_mtx_dereference(sdata->local, sdata->keys[idx]);
+ /*
+ * Silently accept key re-installation without really installing the
+ * new version of the key to avoid nonce reuse or replay issues.
+ */
+ if (old_key && key->conf.keylen == old_key->conf.keylen &&
+ !memcmp(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+ ieee80211_key_free_unused(key);
+ ret = 0;
+ goto out;
+ }
+
+ key->local = sdata->local;
+ key->sdata = sdata;
+ key->sta = sta;
+
increment_tailroom_need_count(sdata);
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
@@ -645,6 +658,7 @@ int ieee80211_key_link(struct ieee80211_
ret = 0;
}
+ out:
mutex_unlock(&sdata->local->key_mtx);
return ret;
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.4/mac80211-use-constant-time-comparison-with-keys.patch
queue-4.4/mac80211-don-t-compare-tkip-tx-mic-key-in-reinstall-prevention.patch
queue-4.4/mac80211-accept-key-reinstall-without-changing-anything.patch
This is a note to let you know that I've just added the patch titled
Input: ims-psu - check if CDC union descriptor is sane
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ea04efee7635c9120d015dcdeeeb6988130cb67a Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Date: Sat, 7 Oct 2017 11:07:47 -0700
Subject: Input: ims-psu - check if CDC union descriptor is sane
From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
commit ea04efee7635c9120d015dcdeeeb6988130cb67a upstream.
Before trying to use CDC union descriptor, try to validate whether that it
is sane by checking that intf->altsetting->extra is big enough and that
descriptor bLength is not too big and not too small.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/misc/ims-pcu.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -1635,13 +1635,25 @@ ims_pcu_get_cdc_union_desc(struct usb_in
return NULL;
}
- while (buflen > 0) {
+ while (buflen >= sizeof(*union_desc)) {
union_desc = (struct usb_cdc_union_desc *)buf;
+ if (union_desc->bLength > buflen) {
+ dev_err(&intf->dev, "Too large descriptor\n");
+ return NULL;
+ }
+
if (union_desc->bDescriptorType == USB_DT_CS_INTERFACE &&
union_desc->bDescriptorSubType == USB_CDC_UNION_TYPE) {
dev_dbg(&intf->dev, "Found union header\n");
- return union_desc;
+
+ if (union_desc->bLength >= sizeof(*union_desc))
+ return union_desc;
+
+ dev_err(&intf->dev,
+ "Union descriptor to short (%d vs %zd\n)",
+ union_desc->bLength, sizeof(*union_desc));
+ return NULL;
}
buflen -= union_desc->bLength;
Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are
queue-4.4/input-ims-psu-check-if-cdc-union-descriptor-is-sane.patch
This is a note to let you know that I've just added the patch titled
ALSA: seq: Cancel pending autoload work at unbinding device
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-seq-cancel-pending-autoload-work-at-unbinding-device.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fc27fe7e8deef2f37cba3f2be2d52b6ca5eb9d57 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Tue, 12 Sep 2017 12:41:20 +0200
Subject: ALSA: seq: Cancel pending autoload work at unbinding device
From: Takashi Iwai <tiwai(a)suse.de>
commit fc27fe7e8deef2f37cba3f2be2d52b6ca5eb9d57 upstream.
ALSA sequencer core has a mechanism to load the enumerated devices
automatically, and it's performed in an off-load work. This seems
causing some race when a sequencer is removed while the pending
autoload work is running. As syzkaller spotted, it may lead to some
use-after-free:
BUG: KASAN: use-after-free in snd_rawmidi_dev_seq_free+0x69/0x70
sound/core/rawmidi.c:1617
Write of size 8 at addr ffff88006c611d90 by task kworker/2:1/567
CPU: 2 PID: 567 Comm: kworker/2:1 Not tainted 4.13.0+ #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events autoload_drivers
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x192/0x22c lib/dump_stack.c:52
print_address_description+0x78/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x230/0x340 mm/kasan/report.c:409
__asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
snd_rawmidi_dev_seq_free+0x69/0x70 sound/core/rawmidi.c:1617
snd_seq_dev_release+0x4f/0x70 sound/core/seq_device.c:192
device_release+0x13f/0x210 drivers/base/core.c:814
kobject_cleanup lib/kobject.c:648 [inline]
kobject_release lib/kobject.c:677 [inline]
kref_put include/linux/kref.h:70 [inline]
kobject_put+0x145/0x240 lib/kobject.c:694
put_device+0x25/0x30 drivers/base/core.c:1799
klist_devices_put+0x36/0x40 drivers/base/bus.c:827
klist_next+0x264/0x4a0 lib/klist.c:403
next_device drivers/base/bus.c:270 [inline]
bus_for_each_dev+0x17e/0x210 drivers/base/bus.c:312
autoload_drivers+0x3b/0x50 sound/core/seq_device.c:117
process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
kthread+0x324/0x3f0 kernel/kthread.c:231
ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
The fix is simply to assure canceling the autoload work at removing
the device.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/seq/seq_device.c | 3 +++
1 file changed, 3 insertions(+)
--- a/sound/core/seq/seq_device.c
+++ b/sound/core/seq/seq_device.c
@@ -148,8 +148,10 @@ void snd_seq_device_load_drivers(void)
flush_work(&autoload_work);
}
EXPORT_SYMBOL(snd_seq_device_load_drivers);
+#define cancel_autoload_drivers() cancel_work_sync(&autoload_work)
#else
#define queue_autoload_drivers() /* NOP */
+#define cancel_autoload_drivers() /* NOP */
#endif
/*
@@ -159,6 +161,7 @@ static int snd_seq_device_dev_free(struc
{
struct snd_seq_device *dev = device->device_data;
+ cancel_autoload_drivers();
put_device(&dev->dev);
return 0;
}
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-seq-cancel-pending-autoload-work-at-unbinding-device.patch