- 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 months

1
0
0 0

Patch "scsi: sg: fix SG_DXFER_FROM_DEV transfers" 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 SG_DXFER_FROM_DEV transfers 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-sg_dxfer_from_dev-transfers.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 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Fri, 7 Jul 2017 10:56:38 +0200 Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream. SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Reported-by: Chris Clayton <chris2553(a)googlemail.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Acked-by: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -758,8 +758,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ if (hp->dxferp || hp->dxfer_len > 0) return false; return true; - case SG_DXFER_TO_DEV: case SG_DXFER_FROM_DEV: + if (hp->dxfer_len < 0) + return false; + return true; + case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: if (!hp->dxferp || hp->dxfer_len == 0) return false; 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, 9 months

1
0
0 0

Patch "irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis" 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 irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis 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: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.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 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Tue, 6 Mar 2018 15:51:32 +0000 Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> [ardb: trivial tweak of unrelated context] Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -684,7 +684,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) static unsigned long *lpi_bitmap; static u32 lpi_chunks; @@ -1320,11 +1320,10 @@ static struct its_device *its_create_dev dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch queue-4.9/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch

7 years, 9 months

1
0
0 0

Patch "nvme: fix subsystem multiple controllers support check" 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 nvme: fix subsystem multiple controllers support check 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: nvme-fix-subsystem-multiple-controllers-support-check.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 b837b28394fb76993c28bb242db7061ee0417da6 Mon Sep 17 00:00:00 2001 From: Israel Rukshin <israelr(a)mellanox.com> Date: Thu, 4 Jan 2018 17:56:14 +0200 Subject: nvme: fix subsystem multiple controllers support check From: Israel Rukshin <israelr(a)mellanox.com> commit b837b28394fb76993c28bb242db7061ee0417da6 upstream. There is a problem when another module (e.g. nvmet) takes a reference on the nvme block device and the physical nvme drive is removed. In that case nvme_free_ctrl() will not be called and the controller state will be "deleting" or "dead" unless nvmet module releases the block device. Later on, the same nvme drive probes back and nvme_init_subsystem() will be called and fail due to duplicate subnqn (if the nvme device doesn't support subsystem with multiple controllers). This will cause a probe failure. This commit changes the check of multiple controllers support at nvme_init_subsystem() by not counting all the controllers at "dead" or "deleting" state (this is safe because controllers at this state will never be active again). Fixes: ab9e00cc72fa ("nvme: track subsystems") Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Signed-off-by: Israel Rukshin <israelr(a)mellanox.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <keith.busch(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/core.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2052,6 +2052,22 @@ static const struct attribute_group *nvm NULL, }; +static int nvme_active_ctrls(struct nvme_subsystem *subsys) +{ + int count = 0; + struct nvme_ctrl *ctrl; + + mutex_lock(&subsys->lock); + list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry) { + if (ctrl->state != NVME_CTRL_DELETING && + ctrl->state != NVME_CTRL_DEAD) + count++; + } + mutex_unlock(&subsys->lock); + + return count; +} + static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id) { struct nvme_subsystem *subsys, *found; @@ -2090,7 +2106,7 @@ static int nvme_init_subsystem(struct nv * Verify that the subsystem actually supports multiple * controllers, else bail out. */ - if (!(id->cmic & (1 << 1))) { + if (nvme_active_ctrls(found) && !(id->cmic & (1 << 1))) { dev_err(ctrl->device, "ignoring ctrl due to duplicate subnqn (%s).\n", found->subnqn); Patches currently in stable-queue which might be from israelr(a)mellanox.com are queue-4.15/nvme-fix-subsystem-multiple-controllers-support-check.patch

7 years, 9 months

1
0
0 0

Patch "irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis" 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 irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis 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: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.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 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Tue, 6 Mar 2018 15:51:32 +0000 Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1412,7 +1412,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) #define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */ static unsigned long *lpi_bitmap; @@ -2119,11 +2119,10 @@ static struct its_device *its_create_dev dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.15/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch queue-4.15/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch

7 years, 9 months

1
0
0 0

Patch "irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis 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: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.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 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Tue, 6 Mar 2018 15:51:32 +0000 Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1310,7 +1310,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) #define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */ static unsigned long *lpi_bitmap; @@ -2026,11 +2026,10 @@ static struct its_device *its_create_dev dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.14/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch queue-4.14/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch

7 years, 9 months

1
0
0 0

Patch "scsi: sg: only check for dxfer_len greater than 256M" has been added to the 4.4-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.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: scsi-sg-only-check-for-dxfer_len-greater-than-256m.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 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 @@ -762,35 +762,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) @@ -811,7 +782,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.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 9 months

1
0
0 0

Patch "scsi: sg: fix static checker warning in sg_is_valid_dxfer" has been added to the 4.4-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.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: scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.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 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 @@ -770,8 +770,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.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 9 months

1
0
0 0

Patch "scsi: sg: fix SG_DXFER_FROM_DEV transfers" has been added to the 4.4-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 SG_DXFER_FROM_DEV transfers 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: scsi-sg-fix-sg_dxfer_from_dev-transfers.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 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Fri, 7 Jul 2017 10:56:38 +0200 Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream. SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Reported-by: Chris Clayton <chris2553(a)googlemail.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Acked-by: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -769,8 +769,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ if (hp->dxferp || hp->dxfer_len > 0) return false; return true; - case SG_DXFER_TO_DEV: case SG_DXFER_FROM_DEV: + if (hp->dxfer_len < 0) + return false; + return true; + case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: if (!hp->dxferp || hp->dxfer_len == 0) return false; Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 9 months

1
0
0 0

Patch "irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis 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: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.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 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Tue, 6 Mar 2018 15:51:32 +0000 Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> [ardb: trivial tweak of unrelated context] Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -663,7 +663,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) static unsigned long *lpi_bitmap; static u32 lpi_chunks; @@ -1168,11 +1168,10 @@ static struct its_device *its_create_dev dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.4/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch

7 years, 9 months

1
0
0 0

Patch "scsi: sg: only check for dxfer_len greater than 256M" has been added to the 3.18-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 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: scsi-sg-only-check-for-dxfer_len-greater-than-256m.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 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 @@ -762,35 +762,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) @@ -811,7 +782,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-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch

7 years, 9 months

1
0
0 0

Patch "scsi: sg: fix static checker warning in sg_is_valid_dxfer" has been added to the 3.18-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 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: scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.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 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 @@ -770,8 +770,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-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch

7 years, 9 months

1
0
0 0

Patch "scsi: sg: fix SG_DXFER_FROM_DEV transfers" has been added to the 3.18-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 SG_DXFER_FROM_DEV transfers 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: scsi-sg-fix-sg_dxfer_from_dev-transfers.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 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Fri, 7 Jul 2017 10:56:38 +0200 Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream. SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Reported-by: Chris Clayton <chris2553(a)googlemail.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Acked-by: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -769,8 +769,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ if (hp->dxferp || hp->dxfer_len > 0) return false; return true; - case SG_DXFER_TO_DEV: case SG_DXFER_FROM_DEV: + if (hp->dxfer_len < 0) + return false; + return true; + case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: if (!hp->dxferp || hp->dxfer_len == 0) return false; Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch

7 years, 9 months

1
0
0 0

[GIT PULL] commits for Linux 3.18

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 43a69271f55a952895915b69f6c50c90c4abdbcd: Linux 3.18.97 (2018-02-28 10:16:18 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-3.18-15032018 for you to fetch changes up to 205e84a2faf04f381dd449aa9915faad389b14ae: ima: relax requiring a file signature for new files with zero length (2018-03-13 16:20:01 -0400) - ---------------------------------------------------------------- for-greg-3.18-15032018 - ---------------------------------------------------------------- Akinobu Mita (1): spi: omap2-mcspi: poll OMAP2_MCSPI_CHSTAT_RXS for PIO transfer Alexander Potapenko (1): selinux: check for address length in selinux_socket_bind() Andreas Pape (1): batman-adv: handle race condition for claims between gateways Andrew F. Davis (2): ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin ARM: dts: omap3-n900: Fix the audio CODEC's reset pin Andrew Lunn (1): net/faraday: Add missing include of of.h Anton Blanchard (1): powerpc: Avoid taking a data miss on every userspace instruction miss Brian King (1): scsi: ipr: Fix missed EH wakeup Chris Wilson (1): drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Christopher James Halse Rogers (1): drm/radeon: Fail fb creation from imported dma-bufs. Dan Carpenter (2): media: cpia2: Fix a couple off by one bugs ASoC: nuc900: Fix a loop timeout test David Carrillo-Cisneros (2): perf inject: Copy events when reordering events in pipe mode perf session: Don't rely on evlist in pipe mode David Daney (1): MIPS: BPF: Quit clobbering callee saved registers in JIT code. David Engraf (1): timers, sched_clock: Update timeout for clock wrap Davide Caratti (1): sched: act_csum: don't mangle TCP and UDP GSO packets Dedy Lansky (1): wil6210: fix memory access violation in wil_memcpy_from/toio_32 Gao Feng (1): tcp: sysctl: Fix a race to avoid unexpected 0 window from space Geert Uytterhoeven (2): ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks H. Nikolaus Schaller (1): Input: tsc2007 - check for presence and power down tsc2007 during probe Hannes Reinecke (1): scsi: sg: close race condition in sg_remove_sfp_usercontext() Jagdish Gediya (1): mtd: nand: ifc: update bufnum mask for ver >= 2.0.0 Jan Kara (1): reiserfs: Make cancel_old_flush() reliable Janusz Krzysztofik (1): [media] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock Jiri Kosina (1): HID: elo: clear BTN_LEFT mapping Johannes Thumshirn (1): scsi: sg: check for valid direction before starting the request John Johansen (1): apparmor: Make path_max parameter readonly Julien BOIBESSOT (1): tools/usbip: fixes build with musl libc toolchain Kirill A. Shutemov (1): mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative() Liam Beguin (1): video: ARM CLCD: fix dma allocation size Linus Walleij (1): ARM: dts: Adjust moxart IRQ controller and flags Lorenzo Colitti (1): net: xfrm: allow clearing socket xfrm policies. Luca Coelho (1): mac80211: remove BUG() when interface type is invalid Masami Hiramatsu (2): kprobes/x86: Fix kprobe-booster not to boost far call instructions kprobes/x86: Set kprobes pages read-only Mimi Zohar (1): ima: relax requiring a file signature for new files with zero length Miquel Raynal (1): mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]() Mohammed Shafi Shajakhan (1): ath10k: disallow DFS simulation if DFS channel is not enabled Nate Watterson (1): iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range Pan Xinhui (1): powerpc/xmon: Fix an unexpected xmon on/off state change Paul E. McKenney (1): sched: Stop resched_cpu() from sending IPIs to offline CPUs Phil Turnbull (1): fm10k: correctly check if interface is removed Prarit Bhargava (1): PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown() Quan Nguyen (1): drivers: net: xgene: Fix hardware checksum setting Rob Herring (1): of: fix of_device_get_modalias returned length when truncating buffers Roger Quadros (1): ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss Samuel Thibault (1): braille-console: Fix value returned by _braille_console_setup SeongJae Park (1): rcutorture/configinit: Fix build directory error message Shaohua Li (1): blk-throttle: make sure expire time isn't too big Stephane Eranian (1): perf tools: Make perf_event__synthesize_mmap_events() scale Stephen Hemminger (1): veth: set peer GSO values Thomas Petazzoni (1): net: mvpp2: set dma mask and coherent dma mask on PPv2.2 Tobias Jordan (1): spi: sun6i: disable/unprepare clocks on remove Tomasz Kramkowski (1): HID: clamp input to logical range if no null state Valtteri HeikkilÃ¤ (1): HID: reject input outside logical range only if null state is set Vincent StehlÃ© (1): regulator: isl9305: fix array size Xose Vazquez Perez (1): scsi: devinfo: apply to HP XP the same flags as Hitachi VSP Yuyang Du (1): usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control() arch/arm/boot/dts/am335x-pepper.dts | 2 +- arch/arm/boot/dts/moxart-uc7112lx.dts | 2 +- arch/arm/boot/dts/moxart.dtsi | 17 ++++--- arch/arm/boot/dts/omap3-n900.dts | 4 +- arch/arm/boot/dts/r8a7790.dtsi | 7 ++- arch/arm/boot/dts/r8a7791.dtsi | 7 ++- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 + arch/mips/net/bpf_jit.c | 16 ++++-- arch/powerpc/mm/fault.c | 2 +- arch/powerpc/xmon/xmon.c | 17 ++++--- arch/x86/kernel/kprobes/core.c | 6 +++ arch/x86/kernel/kprobes/opt.c | 3 ++ block/blk-throttle.c | 11 ++++ drivers/gpu/drm/drm_irq.c | 14 +++++- drivers/gpu/drm/radeon/radeon_display.c | 6 +++ drivers/hid/hid-elo.c | 6 +++ drivers/hid/hid-input.c | 20 +++++--- drivers/input/touchscreen/tsc2007.c | 8 +++ drivers/iommu/iova.c | 2 +- drivers/media/i2c/soc_camera/ov6650.c | 2 +- drivers/media/usb/cpia2/cpia2_v4l.c | 4 +- drivers/mtd/nand/fsl_ifc_nand.c | 7 +++ drivers/mtd/nand/nand_base.c | 9 +++- drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 + drivers/net/ethernet/faraday/ftgmac100.c | 1 + drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +- drivers/net/ethernet/marvell/mvpp2.c | 14 ++++++ drivers/net/veth.c | 3 ++ drivers/net/wireless/ath/ath10k/debug.c | 9 ++++ drivers/net/wireless/ath/wil6210/main.c | 20 ++++++-- drivers/of/device.c | 2 +- drivers/pci/pci-driver.c | 2 - drivers/scsi/ipr.c | 16 ++++-- drivers/scsi/scsi_devinfo.c | 2 +- drivers/scsi/sg.c | 58 ++++++++++++++++------ drivers/spi/spi-omap2-mcspi.c | 9 ++-- drivers/spi/spi-sun6i.c | 2 +- drivers/usb/gadget/udc/dummy_hcd.c | 20 +++----- drivers/video/fbdev/amba-clcd.c | 4 +- fs/reiserfs/journal.c | 2 +- fs/reiserfs/reiserfs.h | 1 + fs/reiserfs/super.c | 21 +++++--- include/linux/pagemap.h | 4 +- include/linux/platform_data/isl9305.h | 2 +- include/net/tcp.h | 8 +-- kernel/printk/braille.c | 15 +++--- kernel/printk/braille.h | 13 +++-- kernel/sched/core.c | 3 +- kernel/time/sched_clock.c | 5 ++ net/batman-adv/bridge_loop_avoidance.c | 20 ++++++-- net/mac80211/iface.c | 2 +- net/sched/act_csum.c | 12 +++++ net/xfrm/xfrm_policy.c | 2 +- net/xfrm/xfrm_state.c | 7 +++ security/apparmor/lsm.c | 2 +- security/integrity/ima/ima_appraise.c | 3 +- security/selinux/hooks.c | 8 +++ sound/soc/nuc900/nuc900-ac97.c | 4 +- tools/perf/util/event.c | 4 +- tools/perf/util/ordered-events.c | 3 +- tools/perf/util/session.c | 17 +++++-- .../testing/selftests/rcutorture/bin/configinit.sh | 2 +- tools/usb/usbip/src/usbipd.c | 2 +- 64 files changed, 373 insertions(+), 129 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaqvaSAAoJEN6mb/eXdyzc7tYQALBsyf0U6YOF46kIyVK3e/U7 Ti2BOwSqJOdXz3bcOcNMQlja7E6IZOndxKFRgr81JombUMGRpgtQBhsK3MVpcNSd /f6wJ80zvOs+kcGHcn3dUr6EWzUWxbudlq8M6EeL6GiXcd3Kus6yicPTVhC8SvIm 03jVwS5xAOTbKH9lMTXqqxZ1Hu8hAWEuloKsHQBD/PGy6bzKfqv4ob/kTEqvY1oU 31nmmlbgTi9xL+tcDrTz1RTYgXvcO7uAXuss4pfnaeqTCEJMK1SO6o0Pm3OocF+n axMsAptbO48tZRejQQ+HpwatPjS+3APheiXg1l4B7PEBoe1kXNiQLXc8m96a96sm ce+hYwHZydgj6gBLPCAA0nfo0j+Fm8pFdJ3WdlgtJDRRF3urx7zXlLJN3I3djd3m YYd+Y/HKb0CDarAotuBqQKhIbUYDqz4eLPbwJGa66JMKY0HvAahKxlKJRvUMvbiY /moN2hJ3IX732bHuiYPzTGRu06AvUs+PAWaYxNIXA1VC75Bff3momUCd8/jTzeD9 umd9y5Tt/i2e4MicMjO6Eh3UEMvoDEHmqNZpFen+YQeifdrEUDKmbYxUrRWuvFQO dpNURdjChlDzN2HdZ54Zf+suId67J2te8/jAWrRIifhcvME/+50bO27aHiInxKW4 UOtW14rBfo7b7oilwFT8 =MB7b -----END PGP SIGNATURE-----

7 years, 9 months

2
1
0 0

[PATCH] irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis

by Ard Biesheuvel

Commit 4f2c7583e33e upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> [ardb: trivial tweak of unrelated context] Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index acb9d250a905..ac15e5d5d9b2 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -684,7 +684,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) static unsigned long *lpi_bitmap; static u32 lpi_chunks; @@ -1320,11 +1320,10 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); -- 2.11.0

7 years, 9 months

2
5
0 0

v3.9.11 build: 9 failures 9 warnings (v3.9.11)

by Build bot for Mark Brown

Tree/Branch: v3.9.11 Git describe: v3.9.11 Commit: 896f5009ed Linux 3.9.11 Build Time: 0 min 12 sec Passed: 0 / 9 ( 0.00 %) Failed: 9 / 9 (100.00 %) Errors: 4 Warnings: 9 Section Mismatches: 0 Failed defconfigs: arm64-allnoconfig arm64-allmodconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig x86_64-allmodconfig arm64-defconfig Errors: arm64-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm64-allmodconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm-multi_v7_defconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allmodconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm64-defconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 5 warnings 0 mismatches : arm64-allmodconfig 3 warnings 0 mismatches : arm-multi_v7_defconfig 8 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-allnoconfig 4 warnings 0 mismatches : x86_64-allnoconfig 5 warnings 0 mismatches : x86_64-allmodconfig 1 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Errors summary: 4 12 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings Summary: 9 4 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] 3 warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI) 3 /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] 2 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- arm64-allmodconfig : FAIL, 2 errors, 5 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm-multi_v7_defconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 3 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 2 errors, 8 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI) warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI) warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI) /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 2 errors, 1 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 3 errors, 4 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 3 errors, 5 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm64-defconfig : FAIL, 2 errors, 1 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror