From: Greg Kroah-Hartman Date: Mon, 19 Mar 2018 13:50:06 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v4.15.12~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2aecd98b116212854af65646a980499e667ae65e;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch scsi-sg-fix-sg_dxfer_from_dev-transfers.patch scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch --- diff --git a/queue-4.4/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch b/queue-4.4/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch new file mode 100644 index 00000000000..0de4db93005 --- /dev/null +++ b/queue-4.4/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch @@ -0,0 +1,68 @@ +From 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Tue, 6 Mar 2018 15:51:32 +0000 +Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis + +From: Ard Biesheuvel + +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 +[maz: updated comment] +Signed-off-by: Marc Zyngier +[ardb: trivial tweak of unrelated context] +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch b/queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch new file mode 100644 index 00000000000..f1a419b3ffa --- /dev/null +++ b/queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch @@ -0,0 +1,46 @@ +From 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Fri, 7 Jul 2017 10:56:38 +0200 +Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers + +From: Johannes Thumshirn + +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 +Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request") +Reported-by: Chris Clayton +Tested-by: Chris Clayton +Cc: Douglas Gilbert +Reviewed-by: Hannes Reinecke +Tested-by: Chris Clayton +Acked-by: Douglas Gilbert +Signed-off-by: Martin K. Petersen +Cc: Cristian Crinteanu +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch b/queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch new file mode 100644 index 00000000000..a534b104d2e --- /dev/null +++ b/queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch @@ -0,0 +1,44 @@ +From 14074aba4bcda3764c9a702b276308b89901d5b6 Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Mon, 17 Jul 2017 15:11:42 +0200 +Subject: scsi: sg: fix static checker warning in sg_is_valid_dxfer + +From: Johannes Thumshirn + +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 +Reported-by: Colin Ian King +Reported-by: Dan Carpenter +Cc: Douglas Gilbert +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch b/queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch new file mode 100644 index 00000000000..6280c1b6a9f --- /dev/null +++ b/queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch @@ -0,0 +1,76 @@ +From f930c7043663188429cd9b254e9d761edfc101ce Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Thu, 27 Jul 2017 09:11:26 +0200 +Subject: scsi: sg: only check for dxfer_len greater than 256M + +From: Johannes Thumshirn + +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 +Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request) +Reported-by: Jason L Tibbitts III +Tested-by: Jason L Tibbitts III +Suggested-by: Doug Gilbert +Cc: Doug Gilbert +Cc: +Reviewed-by: Hannes Reinecke +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/series b/queue-4.4/series index c629dfe03f3..ad421fc7ca6 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -122,3 +122,7 @@ fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch fs-aio-use-rcu-accessors-for-kioctx_table-table.patch +irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch +scsi-sg-fix-sg_dxfer_from_dev-transfers.patch +scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch +scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch