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

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

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror