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

Patch "spi: sh-msiof: Fix timeout failures for TX-only DMA transfers" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: sh-msiof: Fix timeout failures for TX-only DMA transfers to the 4.15-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: spi-sh-msiof-fix-timeout-failures-for-tx-only-dma-transfers.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Wed, 3 Jan 2018 18:11:14 +0100 Subject: spi: sh-msiof: Fix timeout failures for TX-only DMA transfers From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 89434c3c35081439627baa2225622d5bd12242fe ] When using RX (with or without TX), the DMA interrupt triggers completion when the RX FIFO has been emptied, i.e. after the full transfer has finished. However, when using TX without RX, the DMA interrupt triggers completion as soon as the DMA engine has filled the TX FIFO, i.e. before the full transfer has finished. Then sh_msiof_modify_ctr_wait() will spin until the transfer has really finished and the TFSE bit is cleared, for at most 1 ms. For slow speeds and/or large transfers, this may cause timeouts and transfer failures: spi_sh_msiof e6e10000.spi: failed to shut down hardware 74x164 spi2.0: SPI transfer failed: -110 spi_master spi2: failed to transfer one message from queue 74x164 spi2.0: Failed writing: -110 Fix this by waiting explicitly until the TX FIFO has been emptied. Based on a patch in the BSP by Hiromitsu Yamasaki. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-sh-msiof.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/drivers/spi/spi-sh-msiof.c +++ b/drivers/spi/spi-sh-msiof.c @@ -797,11 +797,21 @@ static int sh_msiof_dma_once(struct sh_m goto stop_dma; } - /* wait for tx fifo to be emptied / rx fifo to be filled */ + /* wait for tx/rx DMA completion */ ret = sh_msiof_wait_for_completion(p); if (ret) goto stop_reset; + if (!rx) { + reinit_completion(&p->done); + sh_msiof_write(p, IER, IER_TEOFE); + + /* wait for tx fifo to be emptied */ + ret = sh_msiof_wait_for_completion(p); + if (ret) + goto stop_reset; + } + /* clear status bits */ sh_msiof_reset_str(p); Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.15/acpi-ec-fix-debugfs_create_-usage.patch queue-4.15/spi-sh-msiof-fix-timeout-failures-for-tx-only-dma-transfers.patch

7 years, 2 months

1
0
0 0

Patch "selftests/net: fix bugs in address and port initialization" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/net: fix bugs in address and port initialization to the 4.15-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: selftests-net-fix-bugs-in-address-and-port-initialization.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Date: Mon, 25 Dec 2017 14:43:04 -0800 Subject: selftests/net: fix bugs in address and port initialization From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> [ Upstream commit d36f45e5b46723cf2d4147173e18c52d4143176d ] Address/port initialization should work correctly regardless of the order in which command line arguments are supplied, E.g, cfg_port should be used to connect to the remote host even if it is processed after -D, src/dst address initialization should not require that [-4|-6] be specified before the -S or -D args, receiver should be able to bind to *.<cfg_port> Achieve this by making sure that the address/port structures are initialized after all command line options are parsed. Store cfg_port in host-byte order, and use htons() to set up the sin_port/sin6_port before bind/connect, so that the network system calls get the correct values in network-byte order. Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com> Acked-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/net/msg_zerocopy.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) --- a/tools/testing/selftests/net/msg_zerocopy.c +++ b/tools/testing/selftests/net/msg_zerocopy.c @@ -259,22 +259,28 @@ static int setup_ip6h(struct ipv6hdr *ip return sizeof(*ip6h); } -static void setup_sockaddr(int domain, const char *str_addr, void *sockaddr) + +static void setup_sockaddr(int domain, const char *str_addr, + struct sockaddr_storage *sockaddr) { struct sockaddr_in6 *addr6 = (void *) sockaddr; struct sockaddr_in *addr4 = (void *) sockaddr; switch (domain) { case PF_INET: + memset(addr4, 0, sizeof(*addr4)); addr4->sin_family = AF_INET; addr4->sin_port = htons(cfg_port); - if (inet_pton(AF_INET, str_addr, &(addr4->sin_addr)) != 1) + if (str_addr && + inet_pton(AF_INET, str_addr, &(addr4->sin_addr)) != 1) error(1, 0, "ipv4 parse error: %s", str_addr); break; case PF_INET6: + memset(addr6, 0, sizeof(*addr6)); addr6->sin6_family = AF_INET6; addr6->sin6_port = htons(cfg_port); - if (inet_pton(AF_INET6, str_addr, &(addr6->sin6_addr)) != 1) + if (str_addr && + inet_pton(AF_INET6, str_addr, &(addr6->sin6_addr)) != 1) error(1, 0, "ipv6 parse error: %s", str_addr); break; default: @@ -603,6 +609,7 @@ static void parse_opts(int argc, char ** sizeof(struct tcphdr) - 40 /* max tcp options */; int c; + char *daddr = NULL, *saddr = NULL; cfg_payload_len = max_payload_len; @@ -627,7 +634,7 @@ static void parse_opts(int argc, char ** cfg_cpu = strtol(optarg, NULL, 0); break; case 'D': - setup_sockaddr(cfg_family, optarg, &cfg_dst_addr); + daddr = optarg; break; case 'i': cfg_ifindex = if_nametoindex(optarg); @@ -638,7 +645,7 @@ static void parse_opts(int argc, char ** cfg_cork_mixed = true; break; case 'p': - cfg_port = htons(strtoul(optarg, NULL, 0)); + cfg_port = strtoul(optarg, NULL, 0); break; case 'r': cfg_rx = true; @@ -647,7 +654,7 @@ static void parse_opts(int argc, char ** cfg_payload_len = strtoul(optarg, NULL, 0); break; case 'S': - setup_sockaddr(cfg_family, optarg, &cfg_src_addr); + saddr = optarg; break; case 't': cfg_runtime_ms = 200 + strtoul(optarg, NULL, 10) * 1000; @@ -660,6 +667,8 @@ static void parse_opts(int argc, char ** break; } } + setup_sockaddr(cfg_family, daddr, &cfg_dst_addr); + setup_sockaddr(cfg_family, saddr, &cfg_src_addr); if (cfg_payload_len > max_payload_len) error(1, 0, "-s: payload exceeds max (%d)", max_payload_len); Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are queue-4.15/selftests-net-fix-bugs-in-address-and-port-initialization.patch queue-4.15/rds-reset-rs-rs_bound_addr-in-rds_add_bound-failure-path.patch

7 years, 2 months

1
0
0 0

Patch "serdev: Fix serdev_uevent failure on ACPI enumerated serdev-controllers" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serdev: Fix serdev_uevent failure on ACPI enumerated serdev-controllers to the 4.15-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: serdev-fix-serdev_uevent-failure-on-acpi-enumerated-serdev-controllers.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Mon, 25 Dec 2017 21:50:45 +0100 Subject: serdev: Fix serdev_uevent failure on ACPI enumerated serdev-controllers From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 7d09995dcb0577b4a56aad7f2bb56f28604e8f1a ] ACPI enumerated serdev-controllers do not have an ACPI companion, the ACPI companion belongs to the serdev-device child of the serdev-controller, not to the controller itself. This was causing serdev_uevent to always return -ENODEV when called on a serdev-controller leading to errors like these: kernel: serial serial0: uevent: failed to send synthetic uevent being logged. This commit modifies serdev_uevent to directly return 0 when called on an ACPI enumerated serdev-controller fixing this. Note: I do not think that setting a modalias on a devicetree enumerated serdev-controller makes sense either. So perhaps the !dev->of_node part of the check can be dropped too, but I'm not entirely sure that doing this on devicetree too is correct. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serdev/core.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/tty/serdev/core.c +++ b/drivers/tty/serdev/core.c @@ -54,6 +54,11 @@ static int serdev_uevent(struct device * int rc; /* TODO: platform modalias */ + + /* ACPI enumerated controllers do not have a modalias */ + if (!dev->of_node && dev->type == &serdev_ctrl_type) + return 0; + rc = acpi_device_uevent_modalias(dev, env); if (rc != -ENODEV) return rc; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.15/serdev-fix-serdev_uevent-failure-on-acpi-enumerated-serdev-controllers.patch queue-4.15/acpi-video-default-lcd_only-to-true-on-win8-ready-and-newer-machines.patch queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/input-goodix-disable-irqs-while-suspended.patch queue-4.15/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch queue-4.15/power-supply-axp288_charger-properly-stop-work-on-probe-error-remove.patch queue-4.15/pinctrl-baytrail-enable-glitch-filter-for-gpios-used-as-interrupts.patch

7 years, 2 months

1
0
0 0

Patch "sdhci: Advertise 2.0v supply on SDIO host controller" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sdhci: Advertise 2.0v supply on SDIO host controller to the 4.15-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: sdhci-advertise-2.0v-supply-on-sdio-host-controller.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Thu, 11 Jan 2018 15:51:58 +0200 Subject: sdhci: Advertise 2.0v supply on SDIO host controller From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> [ Upstream commit 2a609abe71ca59e4bd7139e161eaca2144ae6f2e ] On Intel Edison the Broadcom Wi-Fi card, which is connected to SDIO, requires 2.0v, while the host, according to Intel Merrifield TRM, supports 1.8v supply only. The card announces itself as mmc2: new ultra high speed DDR50 SDIO card at address 0001 Introduce a custom OCR mask for SDIO host controller on Intel Merrifield and add a special case to sdhci_set_power_noreg() to override 2.0v supply by enforcing 1.8v power choice. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-pci-core.c | 2 ++ drivers/mmc/host/sdhci.c | 7 +++++++ 2 files changed, 9 insertions(+) --- a/drivers/mmc/host/sdhci-pci-core.c +++ b/drivers/mmc/host/sdhci-pci-core.c @@ -805,6 +805,8 @@ static int intel_mrfld_mmc_probe_slot(st slot->host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; break; case INTEL_MRFLD_SDIO: + /* Advertise 2.0v for compatibility with the SDIO card's OCR */ + slot->host->ocr_mask = MMC_VDD_20_21 | MMC_VDD_165_195; slot->host->mmc->caps |= MMC_CAP_NONREMOVABLE | MMC_CAP_POWER_OFF_CARD; break; --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1470,6 +1470,13 @@ void sdhci_set_power_noreg(struct sdhci_ if (mode != MMC_POWER_OFF) { switch (1 << vdd) { case MMC_VDD_165_195: + /* + * Without a regulator, SDHCI does not support 2.0v + * so we only get here if the driver deliberately + * added the 2.0v range to ocr_avail. Map it to 1.8v + * for the purpose of turning on the power. + */ + case MMC_VDD_20_21: pwr = SDHCI_POWER_180; break; case MMC_VDD_29_30: Patches currently in stable-queue which might be from andriy.shevchenko(a)linux.intel.com are queue-4.15/bluetooth-hci_bcm-mandate-presence-of-shutdown-and-device-wake-gpio.patch queue-4.15/bluetooth-hci_bcm-validate-irq-before-using-it.patch queue-4.15/sdhci-advertise-2.0v-supply-on-sdio-host-controller.patch

7 years, 2 months

1
0
0 0

Patch "scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called to the 4.15-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-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Date: Fri, 5 Jan 2018 05:27:41 -0800 Subject: scsi: megaraid_sas: unload flag should be set after scsi_remove_host is called From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> [ Upstream commit f3f7920b3910171b2999c7dc2335eb9f583e44f2 ] Issue - Driver returns DID_NO_CONNECT when unload is in progress, indicated using instance->unload flag. In case of dynamic unload of driver, this flag is set before calling scsi_remove_host(). While doing manual driver unload, user will see lots of prints for Sync Cache command with DID_NO_CONNECT status. Fix - Set the instance->unload flag after scsi_remove_host(). Allow device removal process to be completed and do not block any command before that. SCSI commands (like SYNC_CACHE) are received (as part of scsi_remove_host) by driver during unload will be submitted further down to the drives. Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -6822,7 +6822,6 @@ static void megasas_detach_one(struct pc u32 pd_seq_map_sz; instance = pci_get_drvdata(pdev); - instance->unload = 1; host = instance->host; fusion = instance->ctrl_context; @@ -6833,6 +6832,7 @@ static void megasas_detach_one(struct pc if (instance->fw_crash_state != UNAVAILABLE) megasas_free_host_crash_buffer(instance); scsi_remove_host(instance->host); + instance->unload = 1; if (megasas_wait_for_adapter_operational(instance)) goto skip_firing_dcmds; Patches currently in stable-queue which might be from shivasharan.srikanteshwara(a)broadcom.com are queue-4.15/scsi-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.patch queue-4.15/scsi-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.patch

7 years, 2 months

1
0
0 0

Patch "scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag." has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. to the 4.15-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-mpt3sas-proper-handling-of-set-clear-of-ata-command-pending-flag.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Chaitra P B <chaitra.basappa(a)broadcom.com> Date: Wed, 27 Dec 2017 23:09:11 -0800 Subject: scsi: mpt3sas: Proper handling of set/clear of "ATA command pending" flag. From: Chaitra P B <chaitra.basappa(a)broadcom.com> [ Upstream commit f49d4aed1315a7b766d855f1367142e682b0cc87 ] 1. In IO path, setting of "ATA command pending" flag early before device removal, invalid device handle etc., checks causes any new commands to be always returned with SAM_STAT_BUSY and when the driver removes the drive the SML issues SYNC Cache command and that command is always returned with SAM_STAT_BUSY and thus making SYNC Cache command to requeued. 2. If the driver gets an ATA PT command for a SATA drive then the driver set "ATA command pending" flag in device specific data structure not to allow any further commands until the ATA PT command is completed. However, after setting the flag if the driver decides to return the command back to upper layers without actually issuing to the firmware (i.e., returns from qcmd failure return paths) then the corresponding flag is not cleared and this prevents the driver from sending any new commands to the drive. This patch fixes above two issues by setting of "ATA command pending" flag after checking for whether device deleted, invalid device handle, device busy with task management. And by setting "ATA command pending" flag to false in all of the qcmd failure return paths after setting the flag. Signed-off-by: Chaitra P B <chaitra.basappa(a)broadcom.com> Signed-off-by: Suganath Prabu S <suganath-prabu.subramani(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -4761,19 +4761,6 @@ scsih_qcmd(struct Scsi_Host *shost, stru return 0; } - /* - * Bug work around for firmware SATL handling. The loop - * is based on atomic operations and ensures consistency - * since we're lockless at this point - */ - do { - if (test_bit(0, &sas_device_priv_data->ata_command_pending)) { - scmd->result = SAM_STAT_BUSY; - scmd->scsi_done(scmd); - return 0; - } - } while (_scsih_set_satl_pending(scmd, true)); - sas_target_priv_data = sas_device_priv_data->sas_target; /* invalid device handle */ @@ -4799,6 +4786,19 @@ scsih_qcmd(struct Scsi_Host *shost, stru sas_device_priv_data->block) return SCSI_MLQUEUE_DEVICE_BUSY; + /* + * Bug work around for firmware SATL handling. The loop + * is based on atomic operations and ensures consistency + * since we're lockless at this point + */ + do { + if (test_bit(0, &sas_device_priv_data->ata_command_pending)) { + scmd->result = SAM_STAT_BUSY; + scmd->scsi_done(scmd); + return 0; + } + } while (_scsih_set_satl_pending(scmd, true)); + if (scmd->sc_data_direction == DMA_FROM_DEVICE) mpi_control = MPI2_SCSIIO_CONTROL_READ; else if (scmd->sc_data_direction == DMA_TO_DEVICE) @@ -4826,6 +4826,7 @@ scsih_qcmd(struct Scsi_Host *shost, stru if (!smid) { pr_err(MPT3SAS_FMT "%s: failed obtaining a smid\n", ioc->name, __func__); + _scsih_set_satl_pending(scmd, false); goto out; } mpi_request = mpt3sas_base_get_msg_frame(ioc, smid); @@ -4857,6 +4858,7 @@ scsih_qcmd(struct Scsi_Host *shost, stru pcie_device = sas_target_priv_data->pcie_dev; if (ioc->build_sg_scmd(ioc, scmd, smid, pcie_device)) { mpt3sas_base_free_smid(ioc, smid); + _scsih_set_satl_pending(scmd, false); goto out; } } else Patches currently in stable-queue which might be from chaitra.basappa(a)broadcom.com are queue-4.15/scsi-mpt3sas-proper-handling-of-set-clear-of-ata-command-pending-flag.patch

7 years, 2 months

1
0
0 0

Patch "scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map to the 4.15-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-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Date: Fri, 5 Jan 2018 05:27:40 -0800 Subject: scsi: megaraid_sas: Error handling for invalid ldcount provided by firmware in RAID map From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> [ Upstream commit 7ada701d0d5e5c6d357e157a72b841db3e8d03f4 ] Currently driver does not validate ldcount provided by firmware. If the value is invalid, fail RAID map validation accordingly. This issue is rare to hit in field and is fixed as part of code review. Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/megaraid/megaraid_sas_fp.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/drivers/scsi/megaraid/megaraid_sas_fp.c +++ b/drivers/scsi/megaraid/megaraid_sas_fp.c @@ -168,7 +168,7 @@ static struct MR_LD_SPAN *MR_LdSpanPtrGe /* * This function will Populate Driver Map using firmware raid map */ -void MR_PopulateDrvRaidMap(struct megasas_instance *instance) +static int MR_PopulateDrvRaidMap(struct megasas_instance *instance) { struct fusion_context *fusion = instance->ctrl_context; struct MR_FW_RAID_MAP_ALL *fw_map_old = NULL; @@ -259,7 +259,7 @@ void MR_PopulateDrvRaidMap(struct megasa ld_count = (u16)le16_to_cpu(fw_map_ext->ldCount); if (ld_count > MAX_LOGICAL_DRIVES_EXT) { dev_dbg(&instance->pdev->dev, "megaraid_sas: LD count exposed in RAID map in not valid\n"); - return; + return 1; } pDrvRaidMap->ldCount = (__le16)cpu_to_le16(ld_count); @@ -285,6 +285,12 @@ void MR_PopulateDrvRaidMap(struct megasa fusion->ld_map[(instance->map_id & 1)]; pFwRaidMap = &fw_map_old->raidMap; ld_count = (u16)le32_to_cpu(pFwRaidMap->ldCount); + if (ld_count > MAX_LOGICAL_DRIVES) { + dev_dbg(&instance->pdev->dev, + "LD count exposed in RAID map in not valid\n"); + return 1; + } + pDrvRaidMap->totalSize = pFwRaidMap->totalSize; pDrvRaidMap->ldCount = (__le16)cpu_to_le16(ld_count); pDrvRaidMap->fpPdIoTimeoutSec = pFwRaidMap->fpPdIoTimeoutSec; @@ -300,6 +306,8 @@ void MR_PopulateDrvRaidMap(struct megasa sizeof(struct MR_DEV_HANDLE_INFO) * MAX_RAIDMAP_PHYSICAL_DEVICES); } + + return 0; } /* @@ -317,8 +325,8 @@ u8 MR_ValidateMapInfo(struct megasas_ins u16 ld; u32 expected_size; - - MR_PopulateDrvRaidMap(instance); + if (MR_PopulateDrvRaidMap(instance)) + return 0; fusion = instance->ctrl_context; drv_map = fusion->ld_drv_map[(instance->map_id & 1)]; Patches currently in stable-queue which might be from shivasharan.srikanteshwara(a)broadcom.com are queue-4.15/scsi-megaraid_sas-error-handling-for-invalid-ldcount-provided-by-firmware-in-raid-map.patch queue-4.15/scsi-megaraid_sas-unload-flag-should-be-set-after-scsi_remove_host-is-called.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: Use dynamic alloced work to avoid sas event lost" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: Use dynamic alloced work to avoid sas event lost to the 4.15-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-libsas-use-dynamic-alloced-work-to-avoid-sas-event-lost.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Fri, 8 Dec 2017 17:42:04 +0800 Subject: scsi: libsas: Use dynamic alloced work to avoid sas event lost From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 1c393b970e0f4070e4376d45f89a2d19a5c895d0 ] Now libsas hotplug work is static, every sas event type has its own static work, LLDD driver queues the hotplug work into shost->work_q. If LLDD driver burst posts lots hotplug events to libsas, the hotplug events may pending in the workqueue like shost->work_q new work[PORTE_BYTES_DMAED] --> |[PHYE_LOSS_OF_SIGNAL][PORTE_BYTES_DMAED] -> processing |<-------wait worker to process-------->| In this case, a new PORTE_BYTES_DMAED event coming, libsas try to queue it to shost->work_q, but this work is already pending, so it would be lost. Finally, libsas delete the related sas port and sas devices, but LLDD driver expect libsas add the sas port and devices(last sas event). This patch use dynamic allocated work to avoid this issue. Signed-off-by: Yijing Wang <wangyijing(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: Johannes Thumshirn <jthumshirn(a)suse.de> CC: Ewan Milne <emilne(a)redhat.com> CC: Christoph Hellwig <hch(a)lst.de> CC: Tomas Henzl <thenzl(a)redhat.com> CC: Dan Williams <dan.j.williams(a)intel.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_event.c | 74 ++++++++++++++++++++++++++++--------- drivers/scsi/libsas/sas_init.c | 27 ++++++++++++- drivers/scsi/libsas/sas_internal.h | 6 +++ drivers/scsi/libsas/sas_phy.c | 44 ++++------------------ drivers/scsi/libsas/sas_port.c | 18 ++++----- include/scsi/libsas.h | 17 +++++--- 6 files changed, 115 insertions(+), 71 deletions(-) --- a/drivers/scsi/libsas/sas_event.c +++ b/drivers/scsi/libsas/sas_event.c @@ -29,7 +29,8 @@ int sas_queue_work(struct sas_ha_struct *ha, struct sas_work *sw) { - int rc = 0; + /* it's added to the defer_q when draining so return succeed */ + int rc = 1; if (!test_bit(SAS_HA_REGISTERED, &ha->state)) return 0; @@ -44,19 +45,15 @@ int sas_queue_work(struct sas_ha_struct return rc; } -static int sas_queue_event(int event, unsigned long *pending, - struct sas_work *work, +static int sas_queue_event(int event, struct sas_work *work, struct sas_ha_struct *ha) { - int rc = 0; + unsigned long flags; + int rc; - if (!test_and_set_bit(event, pending)) { - unsigned long flags; - - spin_lock_irqsave(&ha->lock, flags); - rc = sas_queue_work(ha, work); - spin_unlock_irqrestore(&ha->lock, flags); - } + spin_lock_irqsave(&ha->lock, flags); + rc = sas_queue_work(ha, work); + spin_unlock_irqrestore(&ha->lock, flags); return rc; } @@ -66,6 +63,7 @@ void __sas_drain_work(struct sas_ha_stru { struct workqueue_struct *wq = ha->core.shost->work_q; struct sas_work *sw, *_sw; + int ret; set_bit(SAS_HA_DRAINING, &ha->state); /* flush submitters */ @@ -78,7 +76,10 @@ void __sas_drain_work(struct sas_ha_stru clear_bit(SAS_HA_DRAINING, &ha->state); list_for_each_entry_safe(sw, _sw, &ha->defer_q, drain_node) { list_del_init(&sw->drain_node); - sas_queue_work(ha, sw); + ret = sas_queue_work(ha, sw); + if (ret != 1) + sas_free_event(to_asd_sas_event(&sw->work)); + } spin_unlock_irq(&ha->lock); } @@ -119,29 +120,68 @@ void sas_enable_revalidation(struct sas_ if (!test_and_clear_bit(ev, &d->pending)) continue; - sas_queue_event(ev, &d->pending, &d->disc_work[ev].work, ha); + sas_queue_event(ev, &d->disc_work[ev].work, ha); } mutex_unlock(&ha->disco_mutex); } + +static void sas_port_event_worker(struct work_struct *work) +{ + struct asd_sas_event *ev = to_asd_sas_event(work); + + sas_port_event_fns[ev->event](work); + sas_free_event(ev); +} + +static void sas_phy_event_worker(struct work_struct *work) +{ + struct asd_sas_event *ev = to_asd_sas_event(work); + + sas_phy_event_fns[ev->event](work); + sas_free_event(ev); +} + static int sas_notify_port_event(struct asd_sas_phy *phy, enum port_event event) { + struct asd_sas_event *ev; struct sas_ha_struct *ha = phy->ha; + int ret; BUG_ON(event >= PORT_NUM_EVENTS); - return sas_queue_event(event, &phy->port_events_pending, - &phy->port_events[event].work, ha); + ev = sas_alloc_event(phy); + if (!ev) + return -ENOMEM; + + INIT_SAS_EVENT(ev, sas_port_event_worker, phy, event); + + ret = sas_queue_event(event, &ev->work, ha); + if (ret != 1) + sas_free_event(ev); + + return ret; } int sas_notify_phy_event(struct asd_sas_phy *phy, enum phy_event event) { + struct asd_sas_event *ev; struct sas_ha_struct *ha = phy->ha; + int ret; BUG_ON(event >= PHY_NUM_EVENTS); - return sas_queue_event(event, &phy->phy_events_pending, - &phy->phy_events[event].work, ha); + ev = sas_alloc_event(phy); + if (!ev) + return -ENOMEM; + + INIT_SAS_EVENT(ev, sas_phy_event_worker, phy, event); + + ret = sas_queue_event(event, &ev->work, ha); + if (ret != 1) + sas_free_event(ev); + + return ret; } int sas_init_events(struct sas_ha_struct *sas_ha) --- a/drivers/scsi/libsas/sas_init.c +++ b/drivers/scsi/libsas/sas_init.c @@ -39,6 +39,7 @@ #include "../scsi_sas_internal.h" static struct kmem_cache *sas_task_cache; +static struct kmem_cache *sas_event_cache; struct sas_task *sas_alloc_task(gfp_t flags) { @@ -364,8 +365,6 @@ void sas_prep_resume_ha(struct sas_ha_st struct asd_sas_phy *phy = ha->sas_phy[i]; memset(phy->attached_sas_addr, 0, SAS_ADDR_SIZE); - phy->port_events_pending = 0; - phy->phy_events_pending = 0; phy->frame_rcvd_size = 0; } } @@ -555,20 +554,42 @@ sas_domain_attach_transport(struct sas_d } EXPORT_SYMBOL_GPL(sas_domain_attach_transport); + +struct asd_sas_event *sas_alloc_event(struct asd_sas_phy *phy) +{ + gfp_t flags = in_interrupt() ? GFP_ATOMIC : GFP_KERNEL; + + return kmem_cache_zalloc(sas_event_cache, flags); +} + +void sas_free_event(struct asd_sas_event *event) +{ + kmem_cache_free(sas_event_cache, event); +} + /* ---------- SAS Class register/unregister ---------- */ static int __init sas_class_init(void) { sas_task_cache = KMEM_CACHE(sas_task, SLAB_HWCACHE_ALIGN); if (!sas_task_cache) - return -ENOMEM; + goto out; + + sas_event_cache = KMEM_CACHE(asd_sas_event, SLAB_HWCACHE_ALIGN); + if (!sas_event_cache) + goto free_task_kmem; return 0; +free_task_kmem: + kmem_cache_destroy(sas_task_cache); +out: + return -ENOMEM; } static void __exit sas_class_exit(void) { kmem_cache_destroy(sas_task_cache); + kmem_cache_destroy(sas_event_cache); } MODULE_AUTHOR("Luben Tuikov <luben_tuikov(a)adaptec.com>"); --- a/drivers/scsi/libsas/sas_internal.h +++ b/drivers/scsi/libsas/sas_internal.h @@ -61,6 +61,9 @@ int sas_show_oob_mode(enum sas_oob_mode int sas_register_phys(struct sas_ha_struct *sas_ha); void sas_unregister_phys(struct sas_ha_struct *sas_ha); +struct asd_sas_event *sas_alloc_event(struct asd_sas_phy *phy); +void sas_free_event(struct asd_sas_event *event); + int sas_register_ports(struct sas_ha_struct *sas_ha); void sas_unregister_ports(struct sas_ha_struct *sas_ha); @@ -99,6 +102,9 @@ void sas_hae_reset(struct work_struct *w void sas_free_device(struct kref *kref); +extern const work_func_t sas_phy_event_fns[PHY_NUM_EVENTS]; +extern const work_func_t sas_port_event_fns[PORT_NUM_EVENTS]; + #ifdef CONFIG_SCSI_SAS_HOST_SMP extern void sas_smp_host_handler(struct bsg_job *job, struct Scsi_Host *shost); #else --- a/drivers/scsi/libsas/sas_phy.c +++ b/drivers/scsi/libsas/sas_phy.c @@ -35,7 +35,6 @@ static void sas_phye_loss_of_signal(stru struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PHYE_LOSS_OF_SIGNAL, &phy->phy_events_pending); phy->error = 0; sas_deform_port(phy, 1); } @@ -45,7 +44,6 @@ static void sas_phye_oob_done(struct wor struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PHYE_OOB_DONE, &phy->phy_events_pending); phy->error = 0; } @@ -58,8 +56,6 @@ static void sas_phye_oob_error(struct wo struct sas_internal *i = to_sas_internal(sas_ha->core.shost->transportt); - clear_bit(PHYE_OOB_ERROR, &phy->phy_events_pending); - sas_deform_port(phy, 1); if (!port && phy->enabled && i->dft->lldd_control_phy) { @@ -88,8 +84,6 @@ static void sas_phye_spinup_hold(struct struct sas_internal *i = to_sas_internal(sas_ha->core.shost->transportt); - clear_bit(PHYE_SPINUP_HOLD, &phy->phy_events_pending); - phy->error = 0; i->dft->lldd_control_phy(phy, PHY_FUNC_RELEASE_SPINUP_HOLD, NULL); } @@ -99,8 +93,6 @@ static void sas_phye_resume_timeout(stru struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PHYE_RESUME_TIMEOUT, &phy->phy_events_pending); - /* phew, lldd got the phy back in the nick of time */ if (!phy->suspended) { dev_info(&phy->phy->dev, "resume timeout cancelled\n"); @@ -119,39 +111,12 @@ int sas_register_phys(struct sas_ha_stru { int i; - static const work_func_t sas_phy_event_fns[PHY_NUM_EVENTS] = { - [PHYE_LOSS_OF_SIGNAL] = sas_phye_loss_of_signal, - [PHYE_OOB_DONE] = sas_phye_oob_done, - [PHYE_OOB_ERROR] = sas_phye_oob_error, - [PHYE_SPINUP_HOLD] = sas_phye_spinup_hold, - [PHYE_RESUME_TIMEOUT] = sas_phye_resume_timeout, - - }; - - static const work_func_t sas_port_event_fns[PORT_NUM_EVENTS] = { - [PORTE_BYTES_DMAED] = sas_porte_bytes_dmaed, - [PORTE_BROADCAST_RCVD] = sas_porte_broadcast_rcvd, - [PORTE_LINK_RESET_ERR] = sas_porte_link_reset_err, - [PORTE_TIMER_EVENT] = sas_porte_timer_event, - [PORTE_HARD_RESET] = sas_porte_hard_reset, - }; - /* Now register the phys. */ for (i = 0; i < sas_ha->num_phys; i++) { - int k; struct asd_sas_phy *phy = sas_ha->sas_phy[i]; phy->error = 0; INIT_LIST_HEAD(&phy->port_phy_el); - for (k = 0; k < PORT_NUM_EVENTS; k++) { - INIT_SAS_WORK(&phy->port_events[k].work, sas_port_event_fns[k]); - phy->port_events[k].phy = phy; - } - - for (k = 0; k < PHY_NUM_EVENTS; k++) { - INIT_SAS_WORK(&phy->phy_events[k].work, sas_phy_event_fns[k]); - phy->phy_events[k].phy = phy; - } phy->port = NULL; phy->ha = sas_ha; @@ -179,3 +144,12 @@ int sas_register_phys(struct sas_ha_stru return 0; } + +const work_func_t sas_phy_event_fns[PHY_NUM_EVENTS] = { + [PHYE_LOSS_OF_SIGNAL] = sas_phye_loss_of_signal, + [PHYE_OOB_DONE] = sas_phye_oob_done, + [PHYE_OOB_ERROR] = sas_phye_oob_error, + [PHYE_SPINUP_HOLD] = sas_phye_spinup_hold, + [PHYE_RESUME_TIMEOUT] = sas_phye_resume_timeout, + +}; --- a/drivers/scsi/libsas/sas_port.c +++ b/drivers/scsi/libsas/sas_port.c @@ -261,8 +261,6 @@ void sas_porte_bytes_dmaed(struct work_s struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PORTE_BYTES_DMAED, &phy->port_events_pending); - sas_form_port(phy); } @@ -273,8 +271,6 @@ void sas_porte_broadcast_rcvd(struct wor unsigned long flags; u32 prim; - clear_bit(PORTE_BROADCAST_RCVD, &phy->port_events_pending); - spin_lock_irqsave(&phy->sas_prim_lock, flags); prim = phy->sas_prim; spin_unlock_irqrestore(&phy->sas_prim_lock, flags); @@ -288,8 +284,6 @@ void sas_porte_link_reset_err(struct wor struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PORTE_LINK_RESET_ERR, &phy->port_events_pending); - sas_deform_port(phy, 1); } @@ -298,8 +292,6 @@ void sas_porte_timer_event(struct work_s struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PORTE_TIMER_EVENT, &phy->port_events_pending); - sas_deform_port(phy, 1); } @@ -308,8 +300,6 @@ void sas_porte_hard_reset(struct work_st struct asd_sas_event *ev = to_asd_sas_event(work); struct asd_sas_phy *phy = ev->phy; - clear_bit(PORTE_HARD_RESET, &phy->port_events_pending); - sas_deform_port(phy, 1); } @@ -353,3 +343,11 @@ void sas_unregister_ports(struct sas_ha_ sas_deform_port(sas_ha->sas_phy[i], 0); } + +const work_func_t sas_port_event_fns[PORT_NUM_EVENTS] = { + [PORTE_BYTES_DMAED] = sas_porte_bytes_dmaed, + [PORTE_BROADCAST_RCVD] = sas_porte_broadcast_rcvd, + [PORTE_LINK_RESET_ERR] = sas_porte_link_reset_err, + [PORTE_TIMER_EVENT] = sas_porte_timer_event, + [PORTE_HARD_RESET] = sas_porte_hard_reset, +}; --- a/include/scsi/libsas.h +++ b/include/scsi/libsas.h @@ -292,6 +292,7 @@ struct asd_sas_port { struct asd_sas_event { struct sas_work work; struct asd_sas_phy *phy; + int event; }; static inline struct asd_sas_event *to_asd_sas_event(struct work_struct *work) @@ -301,17 +302,21 @@ static inline struct asd_sas_event *to_a return ev; } +static inline void INIT_SAS_EVENT(struct asd_sas_event *ev, + void (*fn)(struct work_struct *), + struct asd_sas_phy *phy, int event) +{ + INIT_SAS_WORK(&ev->work, fn); + ev->phy = phy; + ev->event = event; +} + + /* The phy pretty much is controlled by the LLDD. * The class only reads those fields. */ struct asd_sas_phy { /* private: */ - struct asd_sas_event port_events[PORT_NUM_EVENTS]; - struct asd_sas_event phy_events[PHY_NUM_EVENTS]; - - unsigned long port_events_pending; - unsigned long phy_events_pending; - int error; int suspended; Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-4.15/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.15/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.15/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch queue-4.15/scsi-libsas-use-dynamic-alloced-work-to-avoid-sas-event-lost.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: initialize sas_phy status according to response of DISCOVER" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: initialize sas_phy status according to response of DISCOVER to the 4.15-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-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: chenxiang <chenxiang66(a)hisilicon.com> Date: Thu, 4 Jan 2018 21:04:33 +0800 Subject: scsi: libsas: initialize sas_phy status according to response of DISCOVER From: chenxiang <chenxiang66(a)hisilicon.com> [ Upstream commit affc67788fe5dfffad5cda3d461db5cf2b2ff2b0 ] The status of SAS PHY is in sas_phy->enabled. There is an issue that the status of a remote SAS PHY may be initialized incorrectly: if disable remote SAS PHY through sysfs interface (such as echo 0 > /sys/class/sas_phy/phy-1:0:0/enable), then reboot the system, and we will find the status of remote SAS PHY which is disabled before is 1 (cat /sys/class/sas_phy/phy-1:0:0/enable). But actually the status of remote SAS PHY is disabled and the device attached is not found. In SAS protocol, NEGOTIATED LOGICAL LINK RATE field of DISCOVER response is 0x1 when remote SAS PHY is disabled. So initialize sas_phy->enabled according to the value of NEGOTIATED LOGICAL LINK RATE field. Signed-off-by: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: John Garry <john.garry(a)huawei.com> Signed-off-by: Jason Yan <yanaijie(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> 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)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_expander.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -293,6 +293,7 @@ static void sas_set_ex_phy(struct domain phy->phy->minimum_linkrate = dr->pmin_linkrate; phy->phy->maximum_linkrate = dr->pmax_linkrate; phy->phy->negotiated_linkrate = phy->linkrate; + phy->phy->enabled = (phy->linkrate != SAS_PHY_DISABLED); skip: if (new_phy) Patches currently in stable-queue which might be from chenxiang66(a)hisilicon.com are queue-4.15/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.15/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.15/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch

7 years, 2 months

1
0
0 0

Patch "scsi: libsas: fix memory leak in sas_smp_get_phy_events()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: libsas: fix memory leak in sas_smp_get_phy_events() to the 4.15-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-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018 From: Jason Yan <yanaijie(a)huawei.com> Date: Thu, 4 Jan 2018 21:04:31 +0800 Subject: scsi: libsas: fix memory leak in sas_smp_get_phy_events() From: Jason Yan <yanaijie(a)huawei.com> [ Upstream commit 4a491b1ab11ca0556d2fda1ff1301e862a2d44c4 ] We've got a memory leak with the following producer: while true; do cat /sys/class/sas_phy/phy-1:0:12/invalid_dword_count >/dev/null; done The buffer req is allocated and not freed after we return. Fix it. Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Signed-off-by: Jason Yan <yanaijie(a)huawei.com> CC: John Garry <john.garry(a)huawei.com> CC: chenqilin <chenqilin2(a)huawei.com> CC: chenxiang <chenxiang66(a)hisilicon.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> 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)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/libsas/sas_expander.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/libsas/sas_expander.c +++ b/drivers/scsi/libsas/sas_expander.c @@ -695,6 +695,7 @@ int sas_smp_get_phy_events(struct sas_ph phy->phy_reset_problem_count = scsi_to_u32(&resp[24]); out: + kfree(req); kfree(resp); return res; Patches currently in stable-queue which might be from yanaijie(a)huawei.com are queue-4.15/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.15/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.15/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch queue-4.15/scsi-libsas-use-dynamic-alloced-work-to-avoid-sas-event-lost.patch

7 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror