--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Date: Sat, 7 Oct 2017 22:38:01 +0000
+Subject: bt8xx: fix memory leak
+
+From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+
+
+[ Upstream commit 6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ]
+
+If dvb_attach() fails then we were just printing an error message and
+exiting but the memory allocated to state was not released.
+
+Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
+Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/pci/bt8xx/dvb-bt8xx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/pci/bt8xx/dvb-bt8xx.c
++++ b/drivers/media/pci/bt8xx/dvb-bt8xx.c
+@@ -680,6 +680,7 @@ static void frontend_init(struct dvb_bt8
+ /* DST is not a frontend, attaching the ASIC */
+ if (dvb_attach(dst_attach, state, &card->dvb_adapter) == NULL) {
+ pr_err("%s: Could not find a Twinhan DST\n", __func__);
++ kfree(state);
+ break;
+ }
+ /* Attach other DST peripherals if any */
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Oleh Kravchenko <oleg@kaa.org.ua>
+Date: Sat, 7 Oct 2017 22:38:00 +0000
+Subject: cx231xx: Fix I2C on Internal Master 3 Bus
+
+From: Oleh Kravchenko <oleg@kaa.org.ua>
+
+
+[ Upstream commit 6c5da8031a3abfad259190d35f83d89568b72ee2 ]
+
+Internal Master 3 Bus can send and receive only 4 bytes per time.
+
+Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/cx231xx/cx231xx-core.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/media/usb/cx231xx/cx231xx-core.c
++++ b/drivers/media/usb/cx231xx/cx231xx-core.c
+@@ -365,7 +365,12 @@ int cx231xx_send_vendor_cmd(struct cx231
+ */
+ if ((ven_req->wLength > 4) && ((ven_req->bRequest == 0x4) ||
+ (ven_req->bRequest == 0x5) ||
+- (ven_req->bRequest == 0x6))) {
++ (ven_req->bRequest == 0x6) ||
++
++ /* Internal Master 3 Bus can send
++ * and receive only 4 bytes per time
++ */
++ (ven_req->bRequest == 0x2))) {
+ unsend_size = 0;
+ pdata = ven_req->pBuff;
+
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Jan Kara <jack@suse.cz>
+Date: Sat, 7 Oct 2017 22:37:59 +0000
+Subject: ext4: do not use stripe_width if it is not set
+
+From: Jan Kara <jack@suse.cz>
+
+
+[ Upstream commit 5469d7c3087ecaf760f54b447f11af6061b7c897 ]
+
+Avoid using stripe_width for sbi->s_stripe value if it is not actually
+set. It prevents using the stride for sbi->s_stripe.
+
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/super.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -2441,9 +2441,9 @@ static unsigned long ext4_get_stripe_siz
+
+ if (sbi->s_stripe && sbi->s_stripe <= sbi->s_blocks_per_group)
+ ret = sbi->s_stripe;
+- else if (stripe_width <= sbi->s_blocks_per_group)
++ else if (stripe_width && stripe_width <= sbi->s_blocks_per_group)
+ ret = stripe_width;
+- else if (stride <= sbi->s_blocks_per_group)
++ else if (stride && stride <= sbi->s_blocks_per_group)
+ ret = stride;
+ else
+ ret = 0;
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Jan Kara <jack@suse.cz>
+Date: Sat, 7 Oct 2017 22:37:59 +0000
+Subject: ext4: fix stripe-unaligned allocations
+
+From: Jan Kara <jack@suse.cz>
+
+
+[ Upstream commit d9b22cf9f5466a057f2a4f1e642b469fa9d73117 ]
+
+When a filesystem is created using:
+
+ mkfs.ext4 -b 4096 -E stride=512 <dev>
+
+and we try to allocate 64MB extent, we will end up directly in
+ext4_mb_complex_scan_group(). This is because the request is detected
+as power-of-two allocation (so we start in ext4_mb_regular_allocator()
+with ac_criteria == 0) however the check before
+ext4_mb_simple_scan_group() refuses the direct buddy scan because the
+allocation request is too large. Since cr == 0, the check whether we
+should use ext4_mb_scan_aligned() fails as well and we fall back to
+ext4_mb_complex_scan_group().
+
+Fix the problem by checking for upper limit on power-of-two requests
+directly when detecting them.
+
+Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/mballoc.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/ext4/mballoc.c
++++ b/fs/ext4/mballoc.c
+@@ -2113,8 +2113,10 @@ ext4_mb_regular_allocator(struct ext4_al
+ * We search using buddy data only if the order of the request
+ * is greater than equal to the sbi_s_mb_order2_reqs
+ * You can tune it via /sys/fs/ext4/<partition>/mb_order2_req
++ * We also support searching for power-of-two requests only for
++ * requests upto maximum buddy size we have constructed.
+ */
+- if (i >= sbi->s_mb_order2_reqs) {
++ if (i >= sbi->s_mb_order2_reqs && i <= sb->s_blocksize_bits + 2) {
+ /*
+ * This should tell if fe_len is exactly power of 2
+ */
+@@ -2176,7 +2178,7 @@ repeat:
+ }
+
+ ac->ac_groups_scanned++;
+- if (cr == 0 && ac->ac_2order < sb->s_blocksize_bits+2)
++ if (cr == 0)
+ ext4_mb_simple_scan_group(ac, &e4b);
+ else if (cr == 1 && sbi->s_stripe &&
+ !(ac->ac_g_ex.fe_len % sbi->s_stripe))
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Chris Brandt <chris.brandt@renesas.com>
+Date: Sat, 7 Oct 2017 22:38:00 +0000
+Subject: i2c: riic: correctly finish transfers
+
+From: Chris Brandt <chris.brandt@renesas.com>
+
+
+[ Upstream commit 71ccea095ea1d4efd004dab971be6d599e06fc3f ]
+
+This fixes the condition where the controller has not fully completed its
+final transfer and leaves the bus and controller in a undesirable state.
+
+At the end of the last transmitted byte, the existing driver would just
+signal for a STOP condition to be transmitted then immediately signal
+completion. However, the full STOP procedure might not have fully taken
+place by the time the runtime PM shuts off the peripheral clock, leaving
+the bus in a suspended state.
+
+Alternatively, the STOP condition on the bus may have completed, but when
+the next transaction is requested by the upper layer, not all the
+necessary register cleanup was finished from the last transfer which made
+the driver return BUS BUSY when it really wasn't.
+
+This patch now makes all transmit and receive transactions wait for the
+STOP condition to fully complete before signaling a completed transaction.
+With this new method, runtime PM no longer seems to be an issue.
+
+Fixes: 310c18a41450 ("i2c: riic: add driver")
+Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
+Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-riic.c | 30 +++++++++++++++++++++++-------
+ 1 file changed, 23 insertions(+), 7 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-riic.c
++++ b/drivers/i2c/busses/i2c-riic.c
+@@ -80,6 +80,7 @@
+ #define ICIER_TEIE 0x40
+ #define ICIER_RIE 0x20
+ #define ICIER_NAKIE 0x10
++#define ICIER_SPIE 0x08
+
+ #define ICSR2_NACKF 0x10
+
+@@ -216,11 +217,10 @@ static irqreturn_t riic_tend_isr(int irq
+ return IRQ_NONE;
+ }
+
+- if (riic->is_last || riic->err)
++ if (riic->is_last || riic->err) {
++ riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
+ writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
+-
+- writeb(0, riic->base + RIIC_ICIER);
+- complete(&riic->msg_done);
++ }
+
+ return IRQ_HANDLED;
+ }
+@@ -240,13 +240,13 @@ static irqreturn_t riic_rdrf_isr(int irq
+
+ if (riic->bytes_left == 1) {
+ /* STOP must come before we set ACKBT! */
+- if (riic->is_last)
++ if (riic->is_last) {
++ riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
+ writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
++ }
+
+ riic_clear_set_bit(riic, 0, ICMR3_ACKBT, RIIC_ICMR3);
+
+- writeb(0, riic->base + RIIC_ICIER);
+- complete(&riic->msg_done);
+ } else {
+ riic_clear_set_bit(riic, ICMR3_ACKBT, 0, RIIC_ICMR3);
+ }
+@@ -259,6 +259,21 @@ static irqreturn_t riic_rdrf_isr(int irq
+ return IRQ_HANDLED;
+ }
+
++static irqreturn_t riic_stop_isr(int irq, void *data)
++{
++ struct riic_dev *riic = data;
++
++ /* read back registers to confirm writes have fully propagated */
++ writeb(0, riic->base + RIIC_ICSR2);
++ readb(riic->base + RIIC_ICSR2);
++ writeb(0, riic->base + RIIC_ICIER);
++ readb(riic->base + RIIC_ICIER);
++
++ complete(&riic->msg_done);
++
++ return IRQ_HANDLED;
++}
++
+ static u32 riic_func(struct i2c_adapter *adap)
+ {
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+@@ -326,6 +341,7 @@ static struct riic_irq_desc riic_irqs[]
+ { .res_num = 0, .isr = riic_tend_isr, .name = "riic-tend" },
+ { .res_num = 1, .isr = riic_rdrf_isr, .name = "riic-rdrf" },
+ { .res_num = 2, .isr = riic_tdre_isr, .name = "riic-tdre" },
++ { .res_num = 3, .isr = riic_stop_isr, .name = "riic-stop" },
+ { .res_num = 5, .isr = riic_tend_isr, .name = "riic-nack" },
+ };
+
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Sat, 7 Oct 2017 22:37:59 +0000
+Subject: mmc: s3cmci: include linux/interrupt.h for tasklet_struct
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+
+[ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ]
+
+I got this new build error on today's linux-next
+
+drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type
+ struct tasklet_struct pio_tasklet;
+drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
+drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration]
+
+While I haven't found out why this happened now and not earlier, the
+solution is obvious, we should include the header that defines
+the structure.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/s3cmci.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mmc/host/s3cmci.c
++++ b/drivers/mmc/host/s3cmci.c
+@@ -21,6 +21,7 @@
+ #include <linux/debugfs.h>
+ #include <linux/seq_file.h>
+ #include <linux/gpio.h>
++#include <linux/interrupt.h>
+ #include <linux/irq.h>
+ #include <linux/io.h>
+
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Javier Martinez Canillas <javier@osg.samsung.com>
+Date: Sat, 7 Oct 2017 22:38:00 +0000
+Subject: platform/x86: intel_mid_thermal: Fix module autoload
+
+From: Javier Martinez Canillas <javier@osg.samsung.com>
+
+
+[ Upstream commit a93151a72061e944a4915458b1b1d6d505c03bbf ]
+
+If the driver is built as a module, autoload won't work because the module
+alias information is not filled. So user-space can't match the registered
+device with the corresponding module.
+
+Export the module alias information using the MODULE_DEVICE_TABLE() macro.
+
+Before this patch:
+
+$ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias
+$
+
+After this patch:
+
+$ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias
+alias: platform:msic_thermal
+
+Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/intel_mid_thermal.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/platform/x86/intel_mid_thermal.c
++++ b/drivers/platform/x86/intel_mid_thermal.c
+@@ -551,6 +551,7 @@ static const struct platform_device_id t
+ { "msic_thermal", 1 },
+ { }
+ };
++MODULE_DEVICE_TABLE(platform, therm_id_table);
+
+ static struct platform_driver mid_thermal_driver = {
+ .driver = {
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Stefan Haberland <sth@linux.vnet.ibm.com>
+Date: Sat, 7 Oct 2017 22:38:01 +0000
+Subject: s390/dasd: check for device error pointer within state change interrupts
+
+From: Stefan Haberland <sth@linux.vnet.ibm.com>
+
+
+[ Upstream commit 2202134e48a3b50320aeb9e3dd1186833e9d7e66 ]
+
+Check if the device pointer is valid. Just a sanity check since we already
+are in the int handler of the device.
+
+Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/block/dasd.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/block/dasd.c
++++ b/drivers/s390/block/dasd.c
+@@ -1672,8 +1672,11 @@ void dasd_int_handler(struct ccw_device
+ /* check for for attention message */
+ if (scsw_dstat(&irb->scsw) & DEV_STAT_ATTENTION) {
+ device = dasd_device_from_cdev_locked(cdev);
+- device->discipline->check_attention(device, irb->esw.esw1.lpum);
+- dasd_put_device(device);
++ if (!IS_ERR(device)) {
++ device->discipline->check_attention(device,
++ irb->esw.esw1.lpum);
++ dasd_put_device(device);
++ }
+ }
+
+ if (!cqr)
drm-msm-fix-potential-buffer-overflow-issue.patch
drm-msm-fix-an-integer-overflow-test.patch
x86-microcode-intel-disable-late-loading-on-model-79.patch
+mmc-s3cmci-include-linux-interrupt.h-for-tasklet_struct.patch
+staging-rtl8712u-fix-endian-settings-for-structs-describing-network-packets.patch
+ext4-fix-stripe-unaligned-allocations.patch
+ext4-do-not-use-stripe_width-if-it-is-not-set.patch
+i2c-riic-correctly-finish-transfers.patch
+cx231xx-fix-i2c-on-internal-master-3-bus.patch
+xen-manage-correct-return-value-check-on-xenbus_scanf.patch
+platform-x86-intel_mid_thermal-fix-module-autoload.patch
+staging-lustre-hsm-stack-overrun-in-hai_dump_data_field.patch
+staging-lustre-ptlrpc-skip-lock-if-export-failed.patch
+s390-dasd-check-for-device-error-pointer-within-state-change-interrupts.patch
+bt8xx-fix-memory-leak.patch
+xen-don-t-print-error-message-in-case-of-missing-xenstore-entry.patch
+staging-r8712u-fix-sparse-warning-in-rtl871x_xmit.c.patch
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: frank zago <fzago@cray.com>
+Date: Sat, 7 Oct 2017 22:38:01 +0000
+Subject: staging: lustre: hsm: stack overrun in hai_dump_data_field
+
+From: frank zago <fzago@cray.com>
+
+
+[ Upstream commit 22aadb91c0a0055935109c175f5446abfb130702 ]
+
+The function hai_dump_data_field will do a stack buffer
+overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has
+some data in it.
+
+hai_dump_data_field uses snprintf. But there is no check for
+truncation, and the value returned by snprintf is used as-is. The
+coordinator code calls hai_dump_data_field with 12 bytes in the
+buffer. The 6th byte of data is printed incompletely to make room for
+the terminating NUL. However snprintf still returns 2, so when
+hai_dump_data_field writes the final NUL, it does it outside the
+reserved buffer, in the 13th byte of the buffer. This stack buffer
+overrun hangs my VM.
+
+Fix by checking that there is enough room for the next 2 characters
+plus the NUL terminator. Don't print half bytes. Change the format to
+02X instead of .2X, which makes more sense.
+
+Signed-off-by: frank zago <fzago@cray.com>
+Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171
+Reviewed-on: http://review.whamcloud.com/20338
+Reviewed-by: John L. Hammond <john.hammond@intel.com>
+Reviewed-by: Jean-Baptiste Riaux <riaux.jb@intel.com>
+Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
+Signed-off-by: James Simmons <jsimmons@infradead.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/lustre/lustre/include/lustre/lustre_user.h | 18 +++++--------
+ 1 file changed, 8 insertions(+), 10 deletions(-)
+
+--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
++++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+@@ -1066,23 +1066,21 @@ struct hsm_action_item {
+ * \retval buffer
+ */
+ static inline char *hai_dump_data_field(struct hsm_action_item *hai,
+- char *buffer, int len)
++ char *buffer, size_t len)
+ {
+- int i, sz, data_len;
++ int i, data_len;
+ char *ptr;
+
+ ptr = buffer;
+- sz = len;
+ data_len = hai->hai_len - sizeof(*hai);
+- for (i = 0 ; (i < data_len) && (sz > 0) ; i++) {
+- int cnt;
+-
+- cnt = snprintf(ptr, sz, "%.2X",
+- (unsigned char)hai->hai_data[i]);
+- ptr += cnt;
+- sz -= cnt;
++ for (i = 0; (i < data_len) && (len > 2); i++) {
++ snprintf(ptr, 3, "%02X", (unsigned char)hai->hai_data[i]);
++ ptr += 2;
++ len -= 2;
+ }
++
+ *ptr = '\0';
++
+ return buffer;
+ }
+
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Alexander Boyko <alexander.boyko@seagate.com>
+Date: Sat, 7 Oct 2017 22:38:01 +0000
+Subject: staging: lustre: ptlrpc: skip lock if export failed
+
+From: Alexander Boyko <alexander.boyko@seagate.com>
+
+
+[ Upstream commit 4c43c27ddc461d8473cedd70f2549614641dfbc7 ]
+
+This patch resolves IO vs eviction race.
+After eviction failed export stayed at stale list,
+a client had IO processing and reconnected during it.
+A client sent brw rpc with last lock cookie and new connection.
+The lock with failed export was found and assert was happened.
+ (ost_handler.c:1812:ost_prolong_lock_one())
+ ASSERTION( lock->l_export == opd->opd_exp ) failed:
+
+ 1. Skip the lock at ldlm_handle2lock if lock export failed.
+ 2. Validation of lock for IO was added at hpreq_check(). The lock
+ searching is based on granted interval tree. If server doesn`t
+ have a valid lock, it reply to client with ESTALE.
+
+Signed-off-by: Alexander Boyko <alexander.boyko@seagate.com>
+Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702
+Seagate-bug-id: MRP-2787
+Reviewed-on: http://review.whamcloud.com/18120
+Reviewed-by: Fan Yong <fan.yong@intel.com>
+Reviewed-by: Vitaly Fertman <vitaly.fertman@seagate.com>
+Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
+Signed-off-by: James Simmons <jsimmons@infradead.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/lustre/lustre/ldlm/ldlm_lock.c | 7 +++++++
+ drivers/staging/lustre/lustre/ptlrpc/service.c | 21 ++++++++-------------
+ 2 files changed, 15 insertions(+), 13 deletions(-)
+
+--- a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
++++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
+@@ -573,6 +573,13 @@ struct ldlm_lock *__ldlm_handle2lock(con
+ if (lock == NULL)
+ return NULL;
+
++ if (lock->l_export && lock->l_export->exp_failed) {
++ CDEBUG(D_INFO, "lock export failed: lock %p, exp %p\n",
++ lock, lock->l_export);
++ LDLM_LOCK_PUT(lock);
++ return NULL;
++ }
++
+ /* It's unlikely but possible that someone marked the lock as
+ * destroyed after we did handle2object on it */
+ if (flags == 0 && ((lock->l_flags & LDLM_FL_DESTROYED)== 0)) {
+--- a/drivers/staging/lustre/lustre/ptlrpc/service.c
++++ b/drivers/staging/lustre/lustre/ptlrpc/service.c
+@@ -1506,20 +1506,15 @@ static int ptlrpc_server_hpreq_init(stru
+ * it may hit swab race at LU-1044. */
+ if (req->rq_ops->hpreq_check) {
+ rc = req->rq_ops->hpreq_check(req);
+- /**
+- * XXX: Out of all current
+- * ptlrpc_hpreq_ops::hpreq_check(), only
+- * ldlm_cancel_hpreq_check() can return an error code;
+- * other functions assert in similar places, which seems
+- * odd. What also does not seem right is that handlers
+- * for those RPCs do not assert on the same checks, but
+- * rather handle the error cases. e.g. see
+- * ost_rw_hpreq_check(), and ost_brw_read(),
+- * ost_brw_write().
++ if (rc == -ESTALE) {
++ req->rq_status = rc;
++ ptlrpc_error(req);
++ }
++ /** can only return error,
++ * 0 for normal request,
++ * or 1 for high priority request
+ */
+- if (rc < 0)
+- return rc;
+- LASSERT(rc == 0 || rc == 1);
++ LASSERT(rc <= 1);
+ }
+
+ spin_lock_bh(&req->rq_export->exp_rpc_lock);
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Fri, 10 Feb 2017 21:30:27 -0600
+Subject: staging: r8712u: Fix Sparse warning in rtl871x_xmit.c
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+
+[ Upstream commit 07222e535831b916221dd2a48a3047ec7e45dc72 ]
+
+Sparse reports the following:
+ CHECK drivers/staging/rtl8712/rtl871x_xmit.c
+drivers/staging/rtl8712/rtl871x_xmit.c:350:44: warning: restricted __le32 degrades to integer
+drivers/staging/rtl8712/rtl871x_xmit.c:491:23: warning: incorrect type in initializer (different base types)
+drivers/staging/rtl8712/rtl871x_xmit.c:491:23: expected unsigned short [usertype] *fctrl
+drivers/staging/rtl8712/rtl871x_xmit.c:491:23: got restricted __le16 *<noident>
+drivers/staging/rtl8712/rtl871x_xmit.c:580:36: warning: incorrect type in assignment (different base types)
+drivers/staging/rtl8712/rtl871x_xmit.c:580:36: expected unsigned short [unsigned] [short] [usertype] <noident>
+drivers/staging/rtl8712/rtl871x_xmit.c:580:36: got restricted __be16 [usertype] <noident>
+
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8712/rtl871x_xmit.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/staging/rtl8712/rtl871x_xmit.c
++++ b/drivers/staging/rtl8712/rtl871x_xmit.c
+@@ -340,7 +340,8 @@ sint r8712_update_attrib(struct _adapter
+ /* if in MP_STATE, update pkt_attrib from mp_txcmd, and overwrite
+ * some settings above.*/
+ if (check_fwstate(pmlmepriv, WIFI_MP_STATE) == true)
+- pattrib->priority = (txdesc.txdw1 >> QSEL_SHT) & 0x1f;
++ pattrib->priority =
++ (le32_to_cpu(txdesc.txdw1) >> QSEL_SHT) & 0x1f;
+ return _SUCCESS;
+ }
+
+@@ -481,7 +482,7 @@ static sint make_wlanhdr(struct _adapter
+ struct ieee80211_hdr *pwlanhdr = (struct ieee80211_hdr *)hdr;
+ struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
+ struct qos_priv *pqospriv = &pmlmepriv->qospriv;
+- u16 *fctrl = &pwlanhdr->frame_ctl;
++ __le16 *fctrl = &pwlanhdr->frame_ctl;
+
+ memset(hdr, 0, WLANHDR_OFFSET);
+ SetFrameSubType(fctrl, pattrib->subtype);
+@@ -569,7 +570,7 @@ static sint r8712_put_snap(u8 *data, u16
+ snap->oui[0] = oui[0];
+ snap->oui[1] = oui[1];
+ snap->oui[2] = oui[2];
+- *(u16 *)(data + SNAP_SIZE) = htons(h_proto);
++ *(__be16 *)(data + SNAP_SIZE) = htons(h_proto);
+ return SNAP_SIZE + sizeof(u16);
+ }
+
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Sat, 7 Oct 2017 22:37:59 +0000
+Subject: staging: rtl8712u: Fix endian settings for structs describing network packets
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+
+[ Upstream commit 221c46d28957bd6e2158abc2179ce4a8c9ce07d3 ]
+
+The headers describing a number of network packets do not have the
+correct endian settings for several types of data.
+
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8712/ieee80211.h | 84 ++++++++++++++++++------------------
+ 1 file changed, 42 insertions(+), 42 deletions(-)
+
+--- a/drivers/staging/rtl8712/ieee80211.h
++++ b/drivers/staging/rtl8712/ieee80211.h
+@@ -142,52 +142,52 @@ struct ieee_ibss_seq {
+ };
+
+ struct ieee80211_hdr {
+- u16 frame_ctl;
+- u16 duration_id;
++ __le16 frame_ctl;
++ __le16 duration_id;
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
+- u16 seq_ctl;
++ __le16 seq_ctl;
+ u8 addr4[ETH_ALEN];
+-} __packed;
++} __packed __aligned(2);
+
+ struct ieee80211_hdr_3addr {
+- u16 frame_ctl;
+- u16 duration_id;
++ __le16 frame_ctl;
++ __le16 duration_id;
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
+- u16 seq_ctl;
+-} __packed;
++ __le16 seq_ctl;
++} __packed __aligned(2);
+
+
+ struct ieee80211_hdr_qos {
+- u16 frame_ctl;
+- u16 duration_id;
++ __le16 frame_ctl;
++ __le16 duration_id;
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
+- u16 seq_ctl;
++ __le16 seq_ctl;
+ u8 addr4[ETH_ALEN];
+- u16 qc;
+-} __packed;
++ __le16 qc;
++} __packed __aligned(2);
+
+ struct ieee80211_hdr_3addr_qos {
+- u16 frame_ctl;
+- u16 duration_id;
++ __le16 frame_ctl;
++ __le16 duration_id;
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
+- u16 seq_ctl;
+- u16 qc;
++ __le16 seq_ctl;
++ __le16 qc;
+ } __packed;
+
+ struct eapol {
+ u8 snap[6];
+- u16 ethertype;
++ __be16 ethertype;
+ u8 version;
+ u8 type;
+- u16 length;
++ __le16 length;
+ } __packed;
+
+
+@@ -554,13 +554,13 @@ Total: 28-2340 bytes
+ */
+
+ struct ieee80211_header_data {
+- u16 frame_ctl;
+- u16 duration_id;
++ __le16 frame_ctl;
++ __le16 duration_id;
+ u8 addr1[6];
+ u8 addr2[6];
+ u8 addr3[6];
+- u16 seq_ctrl;
+-};
++ __le16 seq_ctrl;
++} __packed __aligned(2);
+
+ #define BEACON_PROBE_SSID_ID_POSITION 12
+
+@@ -592,18 +592,18 @@ struct ieee80211_info_element {
+ /*
+ * These are the data types that can make up management packets
+ *
+- u16 auth_algorithm;
+- u16 auth_sequence;
+- u16 beacon_interval;
+- u16 capability;
++ __le16 auth_algorithm;
++ __le16 auth_sequence;
++ __le16 beacon_interval;
++ __le16 capability;
+ u8 current_ap[ETH_ALEN];
+- u16 listen_interval;
++ __le16 listen_interval;
+ struct {
+ u16 association_id:14, reserved:2;
+ } __packed;
+- u32 time_stamp[2];
+- u16 reason;
+- u16 status;
++ __le32 time_stamp[2];
++ __le16 reason;
++ __le16 status;
+ */
+
+ #define IEEE80211_DEFAULT_TX_ESSID "Penguin"
+@@ -611,16 +611,16 @@ struct ieee80211_info_element {
+
+ struct ieee80211_authentication {
+ struct ieee80211_header_data header;
+- u16 algorithm;
+- u16 transaction;
+- u16 status;
++ __le16 algorithm;
++ __le16 transaction;
++ __le16 status;
+ } __packed;
+
+ struct ieee80211_probe_response {
+ struct ieee80211_header_data header;
+- u32 time_stamp[2];
+- u16 beacon_interval;
+- u16 capability;
++ __le32 time_stamp[2];
++ __le16 beacon_interval;
++ __le16 capability;
+ struct ieee80211_info_element info_element;
+ } __packed;
+
+@@ -630,16 +630,16 @@ struct ieee80211_probe_request {
+
+ struct ieee80211_assoc_request_frame {
+ struct ieee80211_hdr_3addr header;
+- u16 capability;
+- u16 listen_interval;
++ __le16 capability;
++ __le16 listen_interval;
+ struct ieee80211_info_element_hdr info_element;
+ } __packed;
+
+ struct ieee80211_assoc_response_frame {
+ struct ieee80211_hdr_3addr header;
+- u16 capability;
+- u16 status;
+- u16 aid;
++ __le16 capability;
++ __le16 status;
++ __le16 aid;
+ } __packed;
+
+ struct ieee80211_txb {
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Juergen Gross <jgross@suse.com>
+Date: Tue, 30 May 2017 20:52:26 +0200
+Subject: xen: don't print error message in case of missing Xenstore entry
+
+From: Juergen Gross <jgross@suse.com>
+
+
+[ Upstream commit 4e93b6481c87ea5afde944a32b4908357ec58992 ]
+
+When registering for the Xenstore watch of the node control/sysrq the
+handler will be called at once. Don't issue an error message if the
+Xenstore node isn't there, as it will be created only when an event
+is being triggered.
+
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/xen/manage.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/drivers/xen/manage.c
++++ b/drivers/xen/manage.c
+@@ -272,8 +272,16 @@ static void sysrq_handler(struct xenbus_
+ err = xenbus_transaction_start(&xbt);
+ if (err)
+ return;
+- if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
+- pr_err("Unable to read sysrq code in control/sysrq\n");
++ err = xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key);
++ if (err < 0) {
++ /*
++ * The Xenstore watch fires directly after registering it and
++ * after a suspend/resume cycle. So ENOENT is no error but
++ * might happen in those cases.
++ */
++ if (err != -ENOENT)
++ pr_err("Error %d reading sysrq code in control/sysrq\n",
++ err);
+ xenbus_transaction_end(xbt, 1);
+ return;
+ }
--- /dev/null
+From foo@baz Mon Nov 6 10:42:09 CET 2017
+From: Jan Beulich <JBeulich@suse.com>
+Date: Sat, 7 Oct 2017 22:38:00 +0000
+Subject: xen/manage: correct return value check on xenbus_scanf()
+
+From: Jan Beulich <JBeulich@suse.com>
+
+
+[ Upstream commit 4fed1b125eb6252bde478665fc05d4819f774fa8 ]
+
+A negative return value indicates an error; in fact the function at
+present won't ever return zero.
+
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/xen/manage.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/xen/manage.c
++++ b/drivers/xen/manage.c
+@@ -272,7 +272,7 @@ static void sysrq_handler(struct xenbus_
+ err = xenbus_transaction_start(&xbt);
+ if (err)
+ return;
+- if (!xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key)) {
++ if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
+ pr_err("Unable to read sysrq code in control/sysrq\n");
+ xenbus_transaction_end(xbt, 1);
+ return;