--- /dev/null
+From 5c1ac56b51b9d222ab202dec1ac2f4215346129d Mon Sep 17 00:00:00 2001
+From: Jean Delvare <jdelvare@suse.de>
+Date: Thu, 14 May 2015 14:40:50 +0200
+Subject: firmware: dmi_scan: Fix ordering of product_uuid
+
+From: Jean Delvare <jdelvare@suse.de>
+
+commit 5c1ac56b51b9d222ab202dec1ac2f4215346129d upstream.
+
+In function dmi_present(), dmi_walk_early() calls dmi_table(), which
+calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
+function makes a decision based on the value of global variable
+dmi_ver. The problem is that this variable is set right _after_
+dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0
+regardless of the actual version implemented.
+
+This causes /sys/class/dmi/id/product_uuid to always use the old
+ordering even on systems implementing DMI/SMBIOS 2.6 or later, which
+should use the new ordering.
+
+This is broken since kernel v3.8 for legacy DMI implementations and
+since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3
+implementations with the 64-bit entry point are not affected.
+
+The first breakage does not matter much as in practice legacy DMI
+implementations are always for versions older than 2.6, which is when
+the UUID ordering changed. The second breakage is more problematic as
+it affects the vast majority of x86 systems manufactured since 2009.
+
+Signed-off-by: Jean Delvare <jdelvare@suse.de>
+Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists")
+Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()")
+Acked-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
+Cc: Ben Hutchings <ben@decadent.org.uk>
+Cc: Artem Savkov <artem.savkov@gmail.com>
+Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
+Cc: Matt Fleming <matt.fleming@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/firmware/dmi_scan.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/firmware/dmi_scan.c
++++ b/drivers/firmware/dmi_scan.c
+@@ -499,18 +499,19 @@ static int __init dmi_present(const u8 *
+ buf += 16;
+
+ if (memcmp(buf, "_DMI_", 5) == 0 && dmi_checksum(buf, 15)) {
++ if (smbios_ver)
++ dmi_ver = smbios_ver;
++ else
++ dmi_ver = (buf[14] & 0xF0) << 4 | (buf[14] & 0x0F);
+ dmi_num = get_unaligned_le16(buf + 12);
+ dmi_len = get_unaligned_le16(buf + 6);
+ dmi_base = get_unaligned_le32(buf + 8);
+
+ if (dmi_walk_early(dmi_decode) == 0) {
+ if (smbios_ver) {
+- dmi_ver = smbios_ver;
+ pr_info("SMBIOS %d.%d present.\n",
+ dmi_ver >> 8, dmi_ver & 0xFF);
+ } else {
+- dmi_ver = (buf[14] & 0xF0) << 4 |
+- (buf[14] & 0x0F);
+ pr_info("Legacy DMI %d.%d present.\n",
+ dmi_ver >> 8, dmi_ver & 0xFF);
+ }
--- /dev/null
+From a81157768a00e8cf8a7b43b5ea5cac931262374f Mon Sep 17 00:00:00 2001
+From: Eric Work <work.eric@gmail.com>
+Date: Mon, 18 May 2015 23:26:23 -0700
+Subject: md/raid0: fix restore to sector variable in raid0_make_request
+
+From: Eric Work <work.eric@gmail.com>
+
+commit a81157768a00e8cf8a7b43b5ea5cac931262374f upstream.
+
+The variable "sector" in "raid0_make_request()" was improperly updated
+by a call to "sector_div()" which modifies its first argument in place.
+Commit 47d68979cc968535cb87f3e5f2e6a3533ea48fbd restored this variable
+after the call for later re-use. Unfortunetly the restore was done after
+the referenced variable "bio" was advanced. This lead to the original
+value and the restored value being different. Here we move this line to
+the proper place.
+
+One observed side effect of this bug was discarding a file though
+unlinking would cause an unrelated file's contents to be discarded.
+
+Signed-off-by: NeilBrown <neilb@suse.de>
+Fixes: 47d68979cc96 ("md/raid0: fix bug with chunksize not a power of 2.")
+URL: https://bugzilla.kernel.org/show_bug.cgi?id=98501
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid0.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid0.c
++++ b/drivers/md/raid0.c
+@@ -517,6 +517,9 @@ static void raid0_make_request(struct md
+ ? (sector & (chunk_sects-1))
+ : sector_div(sector, chunk_sects));
+
++ /* Restore due to sector_div */
++ sector = bio->bi_iter.bi_sector;
++
+ if (sectors < bio_sectors(bio)) {
+ split = bio_split(bio, sectors, GFP_NOIO, fs_bio_set);
+ bio_chain(split, bio);
+@@ -524,7 +527,6 @@ static void raid0_make_request(struct md
+ split = bio;
+ }
+
+- sector = bio->bi_iter.bi_sector;
+ zone = find_zone(mddev->private, §or);
+ tmp_dev = map_sector(mddev, zone, sector, §or);
+ split->bi_bdev = tmp_dev->bdev;
--- /dev/null
+From 6e9eac2dcee5e19f125967dd2be3e36558c42fff Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Fri, 8 May 2015 18:19:34 +1000
+Subject: md/raid5: don't record new size if resize_stripes fails.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream.
+
+If any memory allocation in resize_stripes fails we will return
+-ENOMEM, but in some cases we update conf->pool_size anyway.
+
+This means that if we try again, the allocations will be assumed
+to be larger than they are, and badness results.
+
+So only update pool_size if there is no error.
+
+This bug was introduced in 2.6.17 and the patch is suitable for
+-stable.
+
+Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array")
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -1933,7 +1933,8 @@ static int resize_stripes(struct r5conf
+
+ conf->slab_cache = sc;
+ conf->active_name = 1-conf->active_name;
+- conf->pool_size = newsize;
++ if (!err)
++ conf->pool_size = newsize;
+ return err;
+ }
+
--- /dev/null
+From 40cdc7a530c7a075557651a071354bb42b99df08 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Mon, 27 Apr 2015 14:50:13 +0200
+Subject: nfsd/blocklayout: pretend we can send deviceid notifications
+
+From: Christoph Hellwig <hch@lst.de>
+
+commit 40cdc7a530c7a075557651a071354bb42b99df08 upstream.
+
+Commit df52699e4fcef ("NFSv4.1: Don't cache deviceids that have no
+notifications") causes the Linux NFS client to stop caching deviceid's
+unless a server pretends to support deviceid notifications. While this
+behavior is stupid and the language around this area in rfc5661 is a
+mess carified by an errata that I submittted, Trond insists on this
+behavior. Not caching deviceids degrades block layout performance
+massively as a GETDEVICEINFO is fairly expensive.
+
+So add this hack to make the Linux client happy again.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfsd/blocklayout.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/nfsd/blocklayout.c
++++ b/fs/nfsd/blocklayout.c
+@@ -181,6 +181,17 @@ nfsd4_block_proc_layoutcommit(struct ino
+ }
+
+ const struct nfsd4_layout_ops bl_layout_ops = {
++ /*
++ * Pretend that we send notification to the client. This is a blatant
++ * lie to force recent Linux clients to cache our device IDs.
++ * We rarely ever change the device ID, so the harm of leaking deviceids
++ * for a while isn't too bad. Unfortunately RFC5661 is a complete mess
++ * in this regard, but I filed errata 4119 for this a while ago, and
++ * hopefully the Linux client will eventually start caching deviceids
++ * without this again.
++ */
++ .notify_types =
++ NOTIFY_DEVICEID4_DELETE | NOTIFY_DEVICEID4_CHANGE,
+ .proc_getdeviceinfo = nfsd4_block_proc_getdeviceinfo,
+ .encode_getdeviceinfo = nfsd4_block_encode_getdeviceinfo,
+ .proc_layoutget = nfsd4_block_proc_layoutget,
--- /dev/null
+From ebe9cb3bb13e7b9b281969cd279ce70834f7500f Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Tue, 28 Apr 2015 15:41:15 +0200
+Subject: nfsd: fix the check for confirmed openowner in nfs4_preprocess_stateid_op
+
+From: Christoph Hellwig <hch@lst.de>
+
+commit ebe9cb3bb13e7b9b281969cd279ce70834f7500f upstream.
+
+If we find a non-confirmed openowner we jump to exit the function, but do
+not set an error value. Fix this by factoring out a helper to do the
+check and properly set the error from nfsd4_validate_stateid.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfsd/nfs4state.c | 21 +++++++++++----------
+ 1 file changed, 11 insertions(+), 10 deletions(-)
+
+--- a/fs/nfsd/nfs4state.c
++++ b/fs/nfsd/nfs4state.c
+@@ -4386,10 +4386,17 @@ static __be32 check_stateid_generation(s
+ return nfserr_old_stateid;
+ }
+
++static __be32 nfsd4_check_openowner_confirmed(struct nfs4_ol_stateid *ols)
++{
++ if (ols->st_stateowner->so_is_open_owner &&
++ !(openowner(ols->st_stateowner)->oo_flags & NFS4_OO_CONFIRMED))
++ return nfserr_bad_stateid;
++ return nfs_ok;
++}
++
+ static __be32 nfsd4_validate_stateid(struct nfs4_client *cl, stateid_t *stateid)
+ {
+ struct nfs4_stid *s;
+- struct nfs4_ol_stateid *ols;
+ __be32 status = nfserr_bad_stateid;
+
+ if (ZERO_STATEID(stateid) || ONE_STATEID(stateid))
+@@ -4419,13 +4426,7 @@ static __be32 nfsd4_validate_stateid(str
+ break;
+ case NFS4_OPEN_STID:
+ case NFS4_LOCK_STID:
+- ols = openlockstateid(s);
+- if (ols->st_stateowner->so_is_open_owner
+- && !(openowner(ols->st_stateowner)->oo_flags
+- & NFS4_OO_CONFIRMED))
+- status = nfserr_bad_stateid;
+- else
+- status = nfs_ok;
++ status = nfsd4_check_openowner_confirmed(openlockstateid(s));
+ break;
+ default:
+ printk("unknown stateid type %x\n", s->sc_type);
+@@ -4517,8 +4518,8 @@ nfs4_preprocess_stateid_op(struct net *n
+ status = nfs4_check_fh(current_fh, stp);
+ if (status)
+ goto out;
+- if (stp->st_stateowner->so_is_open_owner
+- && !(openowner(stp->st_stateowner)->oo_flags & NFS4_OO_CONFIRMED))
++ status = nfsd4_check_openowner_confirmed(stp);
++ if (status)
+ goto out;
+ status = nfs4_check_openmode(stp, flags);
+ if (status)
--- /dev/null
+From 5006c1052aafa01dab5b0e643b7dac755b41f3bb Mon Sep 17 00:00:00 2001
+From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Date: Wed, 6 May 2015 15:01:31 -0400
+Subject: Revert "HID: logitech-hidpp: support combo keyboard touchpad TK820"
+
+From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+
+commit 5006c1052aafa01dab5b0e643b7dac755b41f3bb upstream.
+
+This reverts commit 3a61e97563d78a2ca10752902449570d8433ce76.
+
+The Logitech TK820 seems to be affected by a firmware bug which
+delays the sending of the keys (pressed, or released, which triggers
+a key-repeat) while holding fingers on the touch sensor.
+This behavior can be observed while using the mouse emulation mode
+if the user moves the finger while typing (highly improbable though).
+Holding the finger still while in the mouse emulation mode does
+not trigger the key repeat problem.
+So better keep things in their previous state to not have to
+explain users that the new key-repeat bug they see is a "feature".
+
+Furthermore, I noticed that I disabled the media keys whith
+this patch. Sorry, my bad.
+
+I think it is best to revert the patch, in all the current
+versions it has been shipped.
+
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/hid-logitech-hidpp.c | 20 --------------------
+ 1 file changed, 20 deletions(-)
+
+--- a/drivers/hid/hid-logitech-hidpp.c
++++ b/drivers/hid/hid-logitech-hidpp.c
+@@ -39,7 +39,6 @@ MODULE_AUTHOR("Nestor Lopez Casado <nlop
+ /* bits 1..20 are reserved for classes */
+ #define HIDPP_QUIRK_DELAYED_INIT BIT(21)
+ #define HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS BIT(22)
+-#define HIDPP_QUIRK_MULTI_INPUT BIT(23)
+
+ /*
+ * There are two hidpp protocols in use, the first version hidpp10 is known
+@@ -701,12 +700,6 @@ static int wtp_input_mapping(struct hid_
+ struct hid_field *field, struct hid_usage *usage,
+ unsigned long **bit, int *max)
+ {
+- struct hidpp_device *hidpp = hid_get_drvdata(hdev);
+-
+- if ((hidpp->quirks & HIDPP_QUIRK_MULTI_INPUT) &&
+- (field->application == HID_GD_KEYBOARD))
+- return 0;
+-
+ return -1;
+ }
+
+@@ -715,10 +708,6 @@ static void wtp_populate_input(struct hi
+ {
+ struct wtp_data *wd = hidpp->private_data;
+
+- if ((hidpp->quirks & HIDPP_QUIRK_MULTI_INPUT) && origin_is_hid_core)
+- /* this is the generic hid-input call */
+- return;
+-
+ __set_bit(EV_ABS, input_dev->evbit);
+ __set_bit(EV_KEY, input_dev->evbit);
+ __clear_bit(EV_REL, input_dev->evbit);
+@@ -1234,10 +1223,6 @@ static int hidpp_probe(struct hid_device
+ if (hidpp->quirks & HIDPP_QUIRK_DELAYED_INIT)
+ connect_mask &= ~HID_CONNECT_HIDINPUT;
+
+- /* Re-enable hidinput for multi-input devices */
+- if (hidpp->quirks & HIDPP_QUIRK_MULTI_INPUT)
+- connect_mask |= HID_CONNECT_HIDINPUT;
+-
+ ret = hid_hw_start(hdev, connect_mask);
+ if (ret) {
+ hid_err(hdev, "%s:hid_hw_start returned error\n", __func__);
+@@ -1285,11 +1270,6 @@ static const struct hid_device_id hidpp_
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
+ USB_DEVICE_ID_LOGITECH_T651),
+ .driver_data = HIDPP_QUIRK_CLASS_WTP },
+- { /* Keyboard TK820 */
+- HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
+- USB_VENDOR_ID_LOGITECH, 0x4102),
+- .driver_data = HIDPP_QUIRK_DELAYED_INIT | HIDPP_QUIRK_MULTI_INPUT |
+- HIDPP_QUIRK_CLASS_WTP },
+
+ { HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE,
+ USB_VENDOR_ID_LOGITECH, HID_ANY_ID)},
kernfs-do-not-account-ino_ida-allocations-to-memcg.patch
tools-vm-fix-page-flags-build.patch
mm-numa-really-disable-numa-balancing-by-default-on-single-node-machines.patch
+nfsd-blocklayout-pretend-we-can-send-deviceid-notifications.patch
+nfsd-fix-the-check-for-confirmed-openowner-in-nfs4_preprocess_stateid_op.patch
+svcrpc-fix-potential-gssx_accept_sec_context-decoding-failures.patch
+firmware-dmi_scan-fix-ordering-of-product_uuid.patch
+thermal-armada-update-armada-380-thermal-sensor-coefficients.patch
+md-raid5-don-t-record-new-size-if-resize_stripes-fails.patch
+md-raid0-fix-restore-to-sector-variable-in-raid0_make_request.patch
+revert-hid-logitech-hidpp-support-combo-keyboard-touchpad-tk820.patch
--- /dev/null
+From 9507271d960a1911a51683888837d75c171cd91f Mon Sep 17 00:00:00 2001
+From: Scott Mayhew <smayhew@redhat.com>
+Date: Tue, 28 Apr 2015 16:29:53 -0400
+Subject: svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures
+
+From: Scott Mayhew <smayhew@redhat.com>
+
+commit 9507271d960a1911a51683888837d75c171cd91f upstream.
+
+In an environment where the KDC is running Active Directory, the
+exported composite name field returned in the context could be large
+enough to span a page boundary. Attaching a scratch buffer to the
+decoding xdr_stream helps deal with those cases.
+
+The case where we saw this was actually due to behavior that's been
+fixed in newer gss-proxy versions, but we're fixing it here too.
+
+Signed-off-by: Scott Mayhew <smayhew@redhat.com>
+Reviewed-by: Simo Sorce <simo@redhat.com>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sunrpc/auth_gss/gss_rpc_xdr.c | 23 ++++++++++++++++-------
+ 1 file changed, 16 insertions(+), 7 deletions(-)
+
+--- a/net/sunrpc/auth_gss/gss_rpc_xdr.c
++++ b/net/sunrpc/auth_gss/gss_rpc_xdr.c
+@@ -793,20 +793,26 @@ int gssx_dec_accept_sec_context(struct r
+ {
+ u32 value_follows;
+ int err;
++ struct page *scratch;
++
++ scratch = alloc_page(GFP_KERNEL);
++ if (!scratch)
++ return -ENOMEM;
++ xdr_set_scratch_buffer(xdr, page_address(scratch), PAGE_SIZE);
+
+ /* res->status */
+ err = gssx_dec_status(xdr, &res->status);
+ if (err)
+- return err;
++ goto out_free;
+
+ /* res->context_handle */
+ err = gssx_dec_bool(xdr, &value_follows);
+ if (err)
+- return err;
++ goto out_free;
+ if (value_follows) {
+ err = gssx_dec_ctx(xdr, res->context_handle);
+ if (err)
+- return err;
++ goto out_free;
+ } else {
+ res->context_handle = NULL;
+ }
+@@ -814,11 +820,11 @@ int gssx_dec_accept_sec_context(struct r
+ /* res->output_token */
+ err = gssx_dec_bool(xdr, &value_follows);
+ if (err)
+- return err;
++ goto out_free;
+ if (value_follows) {
+ err = gssx_dec_buffer(xdr, res->output_token);
+ if (err)
+- return err;
++ goto out_free;
+ } else {
+ res->output_token = NULL;
+ }
+@@ -826,14 +832,17 @@ int gssx_dec_accept_sec_context(struct r
+ /* res->delegated_cred_handle */
+ err = gssx_dec_bool(xdr, &value_follows);
+ if (err)
+- return err;
++ goto out_free;
+ if (value_follows) {
+ /* we do not support upcall servers sending this data. */
+- return -EINVAL;
++ err = -EINVAL;
++ goto out_free;
+ }
+
+ /* res->options */
+ err = gssx_dec_option_array(xdr, &res->options);
+
++out_free:
++ __free_page(scratch);
+ return err;
+ }
--- /dev/null
+From efa86858e1d8970411a140fa1e0c4dd18a8f2a89 Mon Sep 17 00:00:00 2001
+From: Nadav Haklai <nadavh@marvell.com>
+Date: Wed, 15 Apr 2015 19:08:08 +0200
+Subject: thermal: armada: Update Armada 380 thermal sensor coefficients
+
+From: Nadav Haklai <nadavh@marvell.com>
+
+commit efa86858e1d8970411a140fa1e0c4dd18a8f2a89 upstream.
+
+Improve the Armada 380 thermal sensor accuracy by using updated formula.
+The updated formula is:
+Temperature[C degrees] = 0.4761 * tsen_vsen_out - 279.1
+
+Signed-off-by: Nadav Haklai <nadavh@marvell.com>
+Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/thermal/armada_thermal.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/thermal/armada_thermal.c
++++ b/drivers/thermal/armada_thermal.c
+@@ -224,9 +224,9 @@ static const struct armada_thermal_data
+ .is_valid_shift = 10,
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+- .coef_b = 1169498786UL,
+- .coef_m = 2000000UL,
+- .coef_div = 4289,
++ .coef_b = 2931108200UL,
++ .coef_m = 5000000UL,
++ .coef_div = 10502,
+ .inverted = true,
+ };
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
