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

patch "iio: chemical: ccs811: Corrected firmware boot/application mode" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: chemical: ccs811: Corrected firmware boot/application mode to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From b91e146c38b003c899710ede6d05fc824675e386 Mon Sep 17 00:00:00 2001 From: Richard Lai <richard(a)richardman.com> Date: Sat, 17 Feb 2018 16:28:24 +0000 Subject: iio: chemical: ccs811: Corrected firmware boot/application mode transition CCS811 has different I2C register maps in boot and application mode. When CCS811 is in boot mode, register APP_START (0xF4) is used to transit the firmware state from boot to application mode. However, APP_START is not a valid register location when CCS811 is in application mode (refer to "CCS811 Bootloader Register Map" and "CCS811 Application Register Map" in CCS811 datasheet). The driver should not attempt to perform a write to APP_START while CCS811 is in application mode, as this is not a valid or documented register location. When prob function is being called, the driver assumes the CCS811 sensor is in boot mode, and attempts to perform a write to APP_START. Although CCS811 powers-up in boot mode, it may have already been transited to application mode by previous instances, e.g. unload and reload device driver by the system, or explicitly by user. Depending on the system design, CCS811 sensor may be permanently connected to system power source rather than power controlled by GPIO, hence it is possible that the sensor is never power reset, thus the firmware could be in either boot or application mode at any given time when driver prob function is being called. This patch checks the STATUS register before attempting to send a write to APP_START. Only if the firmware is not in application mode and has valid firmware application loaded, then it will continue to start transiting the firmware boot to application mode. Signed-off-by: Richard Lai <richard(a)richardman.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/chemical/ccs811.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/chemical/ccs811.c b/drivers/iio/chemical/ccs811.c index fbe2431f5b81..1ea9f5513b02 100644 --- a/drivers/iio/chemical/ccs811.c +++ b/drivers/iio/chemical/ccs811.c @@ -133,6 +133,9 @@ static int ccs811_start_sensor_application(struct i2c_client *client) if (ret < 0) return ret; + if ((ret & CCS811_STATUS_FW_MODE_APPLICATION)) + return 0; + if ((ret & CCS811_STATUS_APP_VALID_MASK) != CCS811_STATUS_APP_VALID_LOADED) return -EIO; -- 2.16.2

7 years, 6 months

1
0
0 0

[PATCH 1/3] libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs

by Hans de Goede

There have been reports of the Crucial M500 480GB model not working with LPM set to min_power / med_power_with_dipm level. It has not been tested with medium_power, but that typically has no measurable power-savings. Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03 and there is a MU05 update available, but that update does not mention any LPM fixes in its changelog, so the quirk matches all firmware versions. In my experience the LPM problems with (older) Crucial SSDs seem to be limited to higher capacity versions of the SSDs (different firmware?), so this commit adds a NOLPM quirk for the 480 and 960GB versions of the M500, to avoid LPM causing issues with these SSDs. Cc: stable(a)vger.kernel.org Reported-and-tested-by: Martin Steigerwald <martin(a)lichtvoll.de> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/ata/libata-core.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index aec609f80c4e..53400ce09818 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4538,6 +4538,14 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { ATA_HORKAGE_ZERO_AFTER_TRIM | ATA_HORKAGE_NOLPM, }, + /* 480GB+ M500 SSDs have both queued TRIM and LPM issues */ + { "Crucial_CT480M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_ZERO_AFTER_TRIM | + ATA_HORKAGE_NOLPM, }, + { "Crucial_CT960M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_ZERO_AFTER_TRIM | + ATA_HORKAGE_NOLPM, }, + /* devices that don't properly handle queued TRIM commands */ { "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, }, -- 2.14.3

7 years, 6 months

2
3
0 0

[PATCH AUTOSEL for 4.15 01/78] ipmi_si: Fix error handling of platform device

by Sasha Levin

From: Corey Minyard <cminyard(a)mvista.com> [ Upstream commit 174134ac760275457bb0d1560a0dbe6cf8a12ad6 ] Cleanup of platform devices created by the IPMI driver was not being done correctly and could result in a memory leak. So create a local boolean to know how to clean up those platform devices. Reported-by: David Binderman <dcb314(a)hotmail.com> Signed-off-by: Corey Minyard <cminyard(a)mvista.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/char/ipmi/ipmi_si_intf.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c index 71fad747c0c7..7499b0cd8326 100644 --- a/drivers/char/ipmi/ipmi_si_intf.c +++ b/drivers/char/ipmi/ipmi_si_intf.c @@ -2045,6 +2045,7 @@ static int try_smi_init(struct smi_info *new_smi) int rv = 0; int i; char *init_name = NULL; + bool platform_device_registered = false; pr_info(PFX "Trying %s-specified %s state machine at %s address 0x%lx, slave address 0x%x, irq %d\n", ipmi_addr_src_to_str(new_smi->io.addr_source), @@ -2173,6 +2174,7 @@ static int try_smi_init(struct smi_info *new_smi) rv); goto out_err; } + platform_device_registered = true; } dev_set_drvdata(new_smi->io.dev, new_smi); @@ -2279,10 +2281,11 @@ static int try_smi_init(struct smi_info *new_smi) } if (new_smi->pdev) { - platform_device_unregister(new_smi->pdev); + if (platform_device_registered) + platform_device_unregister(new_smi->pdev); + else + platform_device_put(new_smi->pdev); new_smi->pdev = NULL; - } else if (new_smi->pdev) { - platform_device_put(new_smi->pdev); } kfree(init_name); -- 2.14.1

7 years, 6 months

3
80
0 0

[PATCH AUTOSEL for 4.14 01/67] Bluetooth: hci_qca: Avoid setup failure on missing rampatch

by Sasha Levin

From: Loic Poulain <loic.poulain(a)linaro.org> [ Upstream commit ba8f3597900291a93604643017fff66a14546015 ] Assuming that the original code idea was to enable in-band sleeping only if the setup_rome method returns succes and run in 'standard' mode otherwise, we should not return setup_rome return value which makes qca_setup fail if no rampatch/nvm file found. This fixes BT issue on the dragonboard-820C p4 which includes the following QCA controller: hci0: Product:0x00000008 hci0: Patch :0x00000111 hci0: ROM :0x00000302 hci0: SOC :0x00000044 Since there is no rampatch for this controller revision, just make it work as is. Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/bluetooth/hci_qca.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 392f412b4575..c9f0ac083a3e 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -933,6 +933,9 @@ static int qca_setup(struct hci_uart *hu) if (!ret) { set_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags); qca_debugfs_init(hdev); + } else if (ret == -ENOENT) { + /* No patch/nvm-config found, run with original fw/config */ + ret = 0; } /* Setup bdaddr */ -- 2.14.1

7 years, 6 months

3
70
0 0

[PATCH] acpi, numa: fix pxm to online numa node associations

by Dan Williams

Commit 99759869faf1 "acpi: Add acpi_map_pxm_to_online_node()" added support for mapping a given proximity to its nearest, by SLIT distance, online node. However, it sometimes returns unexpected results due to the fact that it switches from comparing the PXM node to the last node that was closer than the current max. for_each_online_node(n) { dist = node_distance(node, n); if (dist < min_dist) { min_dist = dist; node = n; <---- from this point we're using the wrong node for node_distance() Fixes: 99759869faf1 ("acpi: Add acpi_map_pxm_to_online_node()") Cc: <stable(a)vger.kernel.org> Cc: Toshi Kani <toshi.kani(a)hp.com> Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- Rafael, I can take this through the nvdimm tree with your ack. I have a few other nvdimm fixes pending for 4.16. drivers/acpi/numa.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c index 8ccaae3550d2..85167603b9c9 100644 --- a/drivers/acpi/numa.c +++ b/drivers/acpi/numa.c @@ -103,25 +103,27 @@ int acpi_map_pxm_to_node(int pxm) */ int acpi_map_pxm_to_online_node(int pxm) { - int node, n, dist, min_dist; + int node, min_node; node = acpi_map_pxm_to_node(pxm); if (node == NUMA_NO_NODE) node = 0; + min_node = node; if (!node_online(node)) { - min_dist = INT_MAX; + int min_dist = INT_MAX, dist, n; + for_each_online_node(n) { dist = node_distance(node, n); if (dist < min_dist) { min_dist = dist; - node = n; + min_node = n; } } } - return node; + return min_node; } EXPORT_SYMBOL(acpi_map_pxm_to_online_node);

7 years, 6 months

3
3
0 0

[PATCH] ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

by Adam Ford

commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") For linux-4.4.y Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi index 80f6c78..e056704 100644 --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi @@ -90,6 +90,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -137,6 +139,12 @@ OMAP3_CORE1_IOPAD(0x218e, PIN_OUTPUT | MUX_MODE4) /* mcbsp1_fsr.gpio_157 */ >; }; + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; &omap3_pmx_core2 { -- 2.7.4

7 years, 6 months

2
1
0 0

Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode

by Amir Goldstein

On Tue, Mar 13, 2018 at 11:50 PM, Dave Chinner <david(a)fromorbit.com> wrote: > On Tue, Mar 13, 2018 at 04:33:15PM +0200, Amir Goldstein wrote: >> On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch(a)lst.de> wrote: >> > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: >> >> OK, found the patches the fix soft lockups in generic/269 and >> >> assertion in generic/232, so expunging those 2 tests from v4.15.y >> >> test runs. >> > >> > Which patches are those? We should probably backport them to 4.15-stable. >> >> Probably, but I guess Darrick has those in his TODO. >> >> There is this series that refers to failure in generic/232: >> https://marc.info/?l=linux-xfs&m=151701545720824&w=2 >> >> These 2 commits refer to generic/269 specifically in commit message: >> 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate >> be78ff0e7277 xfs: recheck reflink / dirty page status before freeing >> CoW reservations >> and the thread on the second commit also mentions generic/270 >> (I found out the hard way that it also soft locks). >> >> But there are surely more patches for stable in master. >> I recon CC: stable and/or Fixes: tags could have been helpful, >> but I don't see any of those in v4.16-rcX from the core xfs developers. > > AS I always say: if you want to maintain a stable backport kernel > with all the fixes that go into the bleeding edge, you're more than > welcome to do it. > > Everyone else is flat out just keeping up with on going development > and fixing bugs in the kernel as it's moving forward. So if you have > the need for stable backports, please keep backporting patches you > need, testing them and asking the stable maintainers to include > them. > Greg, I tested the patch in question per Darrick's request. I found no regressions with full "auto" run on xfs with reflinks enabled. Please include this patch in stable 4.15. Dave, It is often the case, though maybe not always, that the author of a patch has the knowledge of the 'Fixes' commit and/or the stable kernel version patch is relevant to or would easily apply to. It is therefore a relatively low effort for a developer to include this information as courtesy to stable maintainers, whether they are maintaining kernel.org stable kernels or distro stable kernels. That's just my opinion. Christoph/Darrick, FYI, with stable kernel 4.15.y, I found the following failures with -g auto: Assert (mostly on quota related): generic/232 xfs/222 xfs/305 xfs/440 xfs/442 Soft lockup (likely fixed by be78ff0e7277): generic/269 generic/270 xfs/442 Failures (output mismatch): xfs/170 xfs/191-input-validation xfs/348 Thanks, Amir.

7 years, 6 months

5
8
0 0

Patch "xfs: preserve i_rdev when recycling a reclaimable inode" 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 xfs: preserve i_rdev when recycling a reclaimable inode 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: xfs-preserve-i_rdev-when-recycling-a-reclaimable-inode.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 acd1d71598f7654b6d7718bcbe979992295c672a Mon Sep 17 00:00:00 2001 From: Amir Goldstein <amir73il(a)gmail.com> Date: Fri, 26 Jan 2018 11:24:40 -0800 Subject: xfs: preserve i_rdev when recycling a reclaimable inode From: Amir Goldstein <amir73il(a)gmail.com> commit acd1d71598f7654b6d7718bcbe979992295c672a upstream. Commit 66f364649d870 ("xfs: remove if_rdev") moved storing of rdev value for special inodes to VFS inodes, but forgot to preserve the value of i_rdev when recycling a reclaimable xfs_inode. This was detected by xfstest overlay/017 with inodex=on mount option and xfs base fs. The test does a lookup of overlay chardev and blockdev right after drop caches. Overlayfs inodes hold a reference on underlying xfs inodes when mount option index=on is configured. If drop caches reclaim xfs inodes, before it relclaims overlayfs inodes, that can sometimes leave a reclaimable xfs inode and that test hits that case quite often. When that happens, the xfs inode cache remains broken (zere i_rdev) until the next cycle mount or drop caches. Fixes: 66f364649d870 ("xfs: remove if_rdev") Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_icache.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -295,6 +295,7 @@ xfs_reinit_inode( uint32_t generation = inode->i_generation; uint64_t version = inode->i_version; umode_t mode = inode->i_mode; + dev_t dev = inode->i_rdev; error = inode_init_always(mp->m_super, inode); @@ -302,6 +303,7 @@ xfs_reinit_inode( inode->i_generation = generation; inode->i_version = version; inode->i_mode = mode; + inode->i_rdev = dev; return error; } Patches currently in stable-queue which might be from amir73il(a)gmail.com are queue-4.15/xfs-preserve-i_rdev-when-recycling-a-reclaimable-inode.patch

7 years, 6 months

1
0
0 0

Patch "scsi: sg: only check for dxfer_len greater than 256M" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: only check for dxfer_len greater than 256M 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-sg-only-check-for-dxfer_len-greater-than-256m.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 f930c7043663188429cd9b254e9d761edfc101ce Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Thu, 27 Jul 2017 09:11:26 +0200 Subject: scsi: sg: only check for dxfer_len greater than 256M From: Johannes Thumshirn <jthumshirn(a)suse.de> commit f930c7043663188429cd9b254e9d761edfc101ce upstream. Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the sg_io_hdr_t::dxferp in order to determine if it is a valid request. The only way we can check for bad requests is by checking if the length exceeds 256M. Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request) Reported-by: Jason L Tibbitts III <tibbs(a)math.uh.edu> Tested-by: Jason L Tibbitts III <tibbs(a)math.uh.edu> Suggested-by: Doug Gilbert <dgilbert(a)interlog.com> Cc: Doug Gilbert <dgilbert(a)interlog.com> Cc: <stable(a)vger.kernel.org> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 31 +------------------------------ 1 file changed, 1 insertion(+), 30 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -751,35 +751,6 @@ sg_new_write(Sg_fd *sfp, struct file *fi return count; } -static bool sg_is_valid_dxfer(sg_io_hdr_t *hp) -{ - switch (hp->dxfer_direction) { - case SG_DXFER_NONE: - if (hp->dxferp || hp->dxfer_len > 0) - return false; - return true; - case SG_DXFER_FROM_DEV: - /* - * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp - * can either be NULL or != NULL so there's no point in checking - * it either. So just return true. - */ - return true; - case SG_DXFER_TO_DEV: - case SG_DXFER_TO_FROM_DEV: - if (!hp->dxferp || hp->dxfer_len == 0) - return false; - return true; - case SG_DXFER_UNKNOWN: - if ((!hp->dxferp && hp->dxfer_len) || - (hp->dxferp && hp->dxfer_len == 0)) - return false; - return true; - default: - return false; - } -} - static int sg_common_write(Sg_fd * sfp, Sg_request * srp, unsigned char *cmnd, int timeout, int blocking) @@ -800,7 +771,7 @@ sg_common_write(Sg_fd * sfp, Sg_request "sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n", (int) cmnd[0], (int) hp->cmd_len)); - if (!sg_is_valid_dxfer(hp)) + if (hp->dxfer_len >= SZ_256M) return -EINVAL; k = sg_start_req(srp, cmnd); Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.9/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.9/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.9/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 6 months

1
0
0 0

Patch "scsi: sg: fix static checker warning in sg_is_valid_dxfer" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: fix static checker warning in sg_is_valid_dxfer 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-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.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 14074aba4bcda3764c9a702b276308b89901d5b6 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Mon, 17 Jul 2017 15:11:42 +0200 Subject: scsi: sg: fix static checker warning in sg_is_valid_dxfer From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream. dxfer_len is an unsigned int and we always assign a value > 0 to it, so it doesn't make any sense to check if it is < 0. We can't really check dxferp as well as we have both NULL and not NULL cases in the possible call paths. So just return true for SG_DXFER_FROM_DEV transfer in sg_is_valid_dxfer(). Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Reported-by: Colin Ian King <colin.king(a)canonical.com> Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -759,8 +759,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ return false; return true; case SG_DXFER_FROM_DEV: - if (hp->dxfer_len < 0) - return false; + /* + * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp + * can either be NULL or != NULL so there's no point in checking + * it either. So just return true. + */ return true; case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.9/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.9/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.9/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror