diff options
| author | Zefan Li <lizefan@huawei.com> | 2016-05-13 12:25:57 +0800 |
|---|---|---|
| committer | Zefan Li <lizefan@huawei.com> | 2016-05-13 13:51:21 +0800 |
| commit | be35da7c7e936c195c9090dd7cd712176cc8f9af (patch) | |
| tree | ed94d6fe7f0cad37b4d313c9faf9a5aa9be2192f | |
| parent | 33fb5cf3e29aaab0966ab5124f8981836ec0f614 (diff) | |
| download | linux-3.4.y-queue-be35da7c7e936c195c9090dd7cd712176cc8f9af.tar.gz | |
Add commits to 3.4.y, up to 4.4-rc1
33 files changed, 1989 insertions, 0 deletions
diff --git a/patches/acpi-use-correct-irq-when-uninstalling-acpi-interrupt-handler.patch b/patches/acpi-use-correct-irq-when-uninstalling-acpi-interrupt-handler.patch new file mode 100644 index 0000000..c75d64d --- /dev/null +++ b/patches/acpi-use-correct-irq-when-uninstalling-acpi-interrupt-handler.patch @@ -0,0 +1,74 @@ +From 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a Mon Sep 17 00:00:00 2001 +From: Chen Yu <yu.c.chen@intel.com> +Date: Sun, 25 Oct 2015 01:02:19 +0800 +Subject: ACPI: Use correct IRQ when uninstalling ACPI interrupt handler + +commit 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a upstream. + +Currently when the system is trying to uninstall the ACPI interrupt +handler, it uses acpi_gbl_FADT.sci_interrupt as the IRQ number. +However, the IRQ number that the ACPI interrupt handled is installed +for comes from acpi_gsi_to_irq() and that is the number that should +be used for the handler removal. + +Fix this problem by using the mapped IRQ returned from acpi_gsi_to_irq() +as appropriate. + +Acked-by: Lv Zheng <lv.zheng@intel.com> +Signed-off-by: Chen Yu <yu.c.chen@intel.com> +Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> +[lizf: Backported to 3.4: adjust context] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/acpi/osl.c | 9 ++++++--- + include/linux/acpi.h | 6 ++++++ + 2 files changed, 12 insertions(+), 3 deletions(-) + +--- a/drivers/acpi/osl.c ++++ b/drivers/acpi/osl.c +@@ -85,6 +85,7 @@ static void *acpi_irq_context; + static struct workqueue_struct *kacpid_wq; + static struct workqueue_struct *kacpi_notify_wq; + struct workqueue_struct *kacpi_hotplug_wq; ++unsigned int acpi_sci_irq = INVALID_ACPI_IRQ; + EXPORT_SYMBOL(kacpi_hotplug_wq); + + /* +@@ -612,17 +613,19 @@ acpi_os_install_interrupt_handler(u32 gs + acpi_irq_handler = NULL; + return AE_NOT_ACQUIRED; + } ++ acpi_sci_irq = irq; + + return AE_OK; + } + +-acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler handler) ++acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler) + { +- if (irq != acpi_gbl_FADT.sci_interrupt) ++ if (gsi != acpi_gbl_FADT.sci_interrupt || !acpi_sci_irq_valid()) + return AE_BAD_PARAMETER; + +- free_irq(irq, acpi_irq); ++ free_irq(acpi_sci_irq, acpi_irq); + acpi_irq_handler = NULL; ++ acpi_sci_irq = INVALID_ACPI_IRQ; + + return AE_OK; + } +--- a/include/linux/acpi.h ++++ b/include/linux/acpi.h +@@ -110,6 +110,12 @@ int acpi_unregister_ioapic(acpi_handle h + void acpi_irq_stats_init(void); + extern u32 acpi_irq_handled; + extern u32 acpi_irq_not_handled; ++extern unsigned int acpi_sci_irq; ++#define INVALID_ACPI_IRQ ((unsigned)-1) ++static inline bool acpi_sci_irq_valid(void) ++{ ++ return acpi_sci_irq != INVALID_ACPI_IRQ; ++} + + extern int sbf_port; + extern unsigned long acpi_realmode_flags; diff --git a/patches/alsa-hda-apply-pin-fixup-for-hp-probook-6550b.patch b/patches/alsa-hda-apply-pin-fixup-for-hp-probook-6550b.patch new file mode 100644 index 0000000..e5f8af1 --- /dev/null +++ b/patches/alsa-hda-apply-pin-fixup-for-hp-probook-6550b.patch @@ -0,0 +1,28 @@ +From c932b98c1e47312822d911c1bb76e81ef50e389c Mon Sep 17 00:00:00 2001 +From: Takashi Iwai <tiwai@suse.de> +Date: Wed, 4 Nov 2015 22:39:16 +0100 +Subject: ALSA: hda - Apply pin fixup for HP ProBook 6550b + +commit c932b98c1e47312822d911c1bb76e81ef50e389c upstream. + +HP ProBook 6550b needs the same pin fixup applied to other HP B-series +laptops with docks for making its headphone and dock headphone jacks +working properly. We just need to add the codec SSID to the list. + +Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=191971 +Signed-off-by: Takashi Iwai <tiwai@suse.de> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + sound/pci/hda/patch_sigmatel.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_sigmatel.c ++++ b/sound/pci/hda/patch_sigmatel.c +@@ -4932,6 +4932,7 @@ static int find_mute_led_cfg(struct hda_ + static int hp_blike_system(u32 subsystem_id) + { + switch (subsystem_id) { ++ case 0x103c1473: /* HP ProBook 6550b */ + case 0x103c1520: + case 0x103c1521: + case 0x103c1523: diff --git a/patches/alsa-hda-disable-64bit-address-for-creative-hda-controllers.patch b/patches/alsa-hda-disable-64bit-address-for-creative-hda-controllers.patch new file mode 100644 index 0000000..23bd0de --- /dev/null +++ b/patches/alsa-hda-disable-64bit-address-for-creative-hda-controllers.patch @@ -0,0 +1,44 @@ +From cadd16ea33a938d49aee99edd4758cc76048b399 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai <tiwai@suse.de> +Date: Tue, 27 Oct 2015 14:21:51 +0100 +Subject: ALSA: hda - Disable 64bit address for Creative HDA controllers + +commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream. + +We've had many reports that some Creative sound cards with CA0132 +don't work well. Some reported that it starts working after reloading +the module, while some reported it starts working when a 32bit kernel +is used. All these facts seem implying that the chip fails to +communicate when the buffer is located in 64bit address. + +This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT +flag to the corresponding PCI entries. I casually had a chance to +test an SB Recon3D board, and indeed this seems helping. + +Although this hasn't been tested on all Creative devices, it's safer +to assume that this restriction applies to the rest of them, too. So +the flag is applied to all Creative entries. + +Signed-off-by: Takashi Iwai <tiwai@suse.de> +[lizf: Backported to 3.4: drop the change to macro AZX_DCAPS_PRESET_CTHDA] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + sound/pci/hda/hda_intel.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/pci/hda/hda_intel.c ++++ b/sound/pci/hda/hda_intel.c +@@ -3144,11 +3144,13 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) + .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, + .class_mask = 0xffffff, + .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND | ++ AZX_DCAPS_NO_64BIT | + AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB }, + #else + /* this entry seems still valid -- i.e. without emu20kx chip */ + { PCI_DEVICE(0x1102, 0x0009), + .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND | ++ AZX_DCAPS_NO_64BIT | + AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB }, + #endif + /* Vortex86MX */ diff --git a/patches/arm-pxa-remove-incorrect-__init-annotation-on-pxa27x_set_pwrmode.patch b/patches/arm-pxa-remove-incorrect-__init-annotation-on-pxa27x_set_pwrmode.patch new file mode 100644 index 0000000..e002005 --- /dev/null +++ b/patches/arm-pxa-remove-incorrect-__init-annotation-on-pxa27x_set_pwrmode.patch @@ -0,0 +1,52 @@ +From 54c09889bff6d99c8733eed4a26c9391b177c88b Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann <arnd@arndb.de> +Date: Mon, 12 Oct 2015 15:46:08 +0200 +Subject: ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode + +commit 54c09889bff6d99c8733eed4a26c9391b177c88b upstream. + +The z2 machine calls pxa27x_set_pwrmode() in order to power off +the machine, but this function gets discarded early at boot because +it is marked __init, as pointed out by kbuild: + +WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the function z2_power_off() to the function .init.text:pxa27x_set_pwrmode() +The function z2_power_off() references +the function __init pxa27x_set_pwrmode(). +This is often because z2_power_off lacks a __init +annotation or the annotation of pxa27x_set_pwrmode is wrong. + +This removes the __init section modifier to fix rebooting and the +build error. + +Signed-off-by: Arnd Bergmann <arnd@arndb.de> +Fixes: ba4a90a6d86a ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available") +Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> +[lizf: Backported to 3.4: adjust context] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + arch/arm/mach-pxa/include/mach/pxa27x.h | 2 +- + arch/arm/mach-pxa/pxa27x.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm/mach-pxa/include/mach/pxa27x.h ++++ b/arch/arm/mach-pxa/include/mach/pxa27x.h +@@ -21,7 +21,7 @@ + + extern void __init pxa27x_map_io(void); + extern void __init pxa27x_init_irq(void); +-extern int __init pxa27x_set_pwrmode(unsigned int mode); ++extern int pxa27x_set_pwrmode(unsigned int mode); + extern void pxa27x_cpu_pm_enter(suspend_state_t state); + + #define pxa27x_handle_irq ichp_handle_irq +--- a/arch/arm/mach-pxa/pxa27x.c ++++ b/arch/arm/mach-pxa/pxa27x.c +@@ -242,7 +242,7 @@ static struct clk_lookup pxa27x_clkregs[ + */ + static unsigned int pwrmode = PWRMODE_SLEEP; + +-int __init pxa27x_set_pwrmode(unsigned int mode) ++int pxa27x_set_pwrmode(unsigned int mode) + { + switch (mode) { + case PWRMODE_SLEEP: diff --git a/patches/binfmt_elf-don-t-clobber-passed-executable-s-file-header.patch b/patches/binfmt_elf-don-t-clobber-passed-executable-s-file-header.patch new file mode 100644 index 0000000..3f7ca21 --- /dev/null +++ b/patches/binfmt_elf-don-t-clobber-passed-executable-s-file-header.patch @@ -0,0 +1,59 @@ +From b582ef5c53040c5feef4c96a8f9585b6831e2441 Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" <macro@imgtec.com> +Date: Mon, 26 Oct 2015 15:48:19 +0000 +Subject: binfmt_elf: Don't clobber passed executable's file header + +commit b582ef5c53040c5feef4c96a8f9585b6831e2441 upstream. + +Do not clobber the buffer space passed from `search_binary_handler' and +originally preloaded by `prepare_binprm' with the executable's file +header by overwriting it with its interpreter's file header. Instead +keep the buffer space intact and directly use the data structure locally +allocated for the interpreter's file header, fixing a bug introduced in +2.1.14 with loadable module support (linux-mips.org commit beb11695 +[Import of Linux/MIPS 2.1.14], predating kernel.org repo's history). +Adjust the amount of data read from the interpreter's file accordingly. + +This was not an issue before loadable module support, because back then +`load_elf_binary' was executed only once for a given ELF executable, +whether the function succeeded or failed. + +With loadable module support supported and enabled, upon a failure of +`load_elf_binary' -- which may for example be caused by architecture +code rejecting an executable due to a missing hardware feature requested +in the file header -- a module load is attempted and then the function +reexecuted by `search_binary_handler'. With the executable's file +header replaced with its interpreter's file header the executable can +then be erroneously accepted in this subsequent attempt. + +Signed-off-by: Maciej W. Rozycki <macro@imgtec.com> +Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + fs/binfmt_elf.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/fs/binfmt_elf.c ++++ b/fs/binfmt_elf.c +@@ -668,16 +668,16 @@ static int load_elf_binary(struct linux_ + */ + would_dump(bprm, interpreter); + +- retval = kernel_read(interpreter, 0, bprm->buf, +- BINPRM_BUF_SIZE); +- if (retval != BINPRM_BUF_SIZE) { ++ /* Get the exec headers */ ++ retval = kernel_read(interpreter, 0, ++ (void *)&loc->interp_elf_ex, ++ sizeof(loc->interp_elf_ex)); ++ if (retval != sizeof(loc->interp_elf_ex)) { + if (retval >= 0) + retval = -EIO; + goto out_free_dentry; + } + +- /* Get the exec headers */ +- loc->interp_elf_ex = *((struct elfhdr *)bprm->buf); + break; + } + elf_ppnt++; diff --git a/patches/bluetooth-ath3k-add-support-of-ar3012-0cf3-817b-device.patch b/patches/bluetooth-ath3k-add-support-of-ar3012-0cf3-817b-device.patch new file mode 100644 index 0000000..37ac757 --- /dev/null +++ b/patches/bluetooth-ath3k-add-support-of-ar3012-0cf3-817b-device.patch @@ -0,0 +1,52 @@ +From 18e0afab8ce3f1230ce3fef52b2e73374fd9c0e7 Mon Sep 17 00:00:00 2001 +From: Dmitry Tunin <hanipouspilot@gmail.com> +Date: Fri, 16 Oct 2015 11:45:26 +0300 +Subject: Bluetooth: ath3k: Add support of AR3012 0cf3:817b device + +commit 18e0afab8ce3f1230ce3fef52b2e73374fd9c0e7 upstream. + +T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 +D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 +P: Vendor=0cf3 ProdID=817b Rev=00.02 +C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA +I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb +I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb + +BugLink: https://bugs.launchpad.net/bugs/1506615 + +Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> +Signed-off-by: Marcel Holtmann <marcel@holtmann.org> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/bluetooth/ath3k.c | 2 ++ + drivers/bluetooth/btusb.c | 1 + + 2 files changed, 3 insertions(+) + +--- a/drivers/bluetooth/ath3k.c ++++ b/drivers/bluetooth/ath3k.c +@@ -94,6 +94,7 @@ static struct usb_device_id ath3k_table[ + { USB_DEVICE(0x0CF3, 0x311D) }, + { USB_DEVICE(0x0cf3, 0x3121) }, + { USB_DEVICE(0x0CF3, 0x817a) }, ++ { USB_DEVICE(0x0CF3, 0x817b) }, + { USB_DEVICE(0x0cf3, 0xe003) }, + { USB_DEVICE(0x0CF3, 0xE004) }, + { USB_DEVICE(0x0CF3, 0xE005) }, +@@ -144,6 +145,7 @@ static struct usb_device_id ath3k_blist_ + { USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0CF3, 0x817a), .driver_info = BTUSB_ATH3012 }, ++ { USB_DEVICE(0x0CF3, 0x817b), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 }, +--- a/drivers/bluetooth/btusb.c ++++ b/drivers/bluetooth/btusb.c +@@ -172,6 +172,7 @@ static struct usb_device_id blacklist_ta + { USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0x817a), .driver_info = BTUSB_ATH3012 }, ++ { USB_DEVICE(0x0cf3, 0x817b), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 }, + { USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 }, diff --git a/patches/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch b/patches/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch new file mode 100644 index 0000000..7a828c0 --- /dev/null +++ b/patches/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch @@ -0,0 +1,119 @@ +From 1d512cb77bdbda80f0dd0620a3b260d697fd581d Mon Sep 17 00:00:00 2001 +From: Filipe Manana <fdmanana@suse.com> +Date: Mon, 9 Nov 2015 00:33:58 +0000 +Subject: Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow + +commit 1d512cb77bdbda80f0dd0620a3b260d697fd581d upstream. + +If we are using the NO_HOLES feature, we have a tiny time window when +running delalloc for a nodatacow inode where we can race with a concurrent +link or xattr add operation leading to a BUG_ON. + +This happens because at run_delalloc_nocow() we end up casting a leaf item +of type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a +file extent item (struct btrfs_file_extent_item) and then analyse its +extent type field, which won't match any of the expected extent types +(values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an +explicit BUG_ON(1). + +The following sequence diagram shows how the race happens when running a +no-cow dellaloc range [4K, 8K[ for inode 257 and we have the following +neighbour leafs: + + Leaf X (has N items) Leaf Y + + [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 EXTENT_DATA 8192), ... ] + slot N - 2 slot N - 1 slot 0 + + (Note the implicit hole for inode 257 regarding the [0, 8K[ range) + + CPU 1 CPU 2 + + run_dealloc_nocow() + btrfs_lookup_file_extent() + --> searches for a key with value + (257 EXTENT_DATA 4096) in the + fs/subvol tree + --> returns us a path with + path->nodes[0] == leaf X and + path->slots[0] == N + + because path->slots[0] is >= + btrfs_header_nritems(leaf X), it + calls btrfs_next_leaf() + + btrfs_next_leaf() + --> releases the path + + hard link added to our inode, + with key (257 INODE_REF 500) + added to the end of leaf X, + so leaf X now has N + 1 keys + + --> searches for the key + (257 INODE_REF 256), because + it was the last key in leaf X + before it released the path, + with path->keep_locks set to 1 + + --> ends up at leaf X again and + it verifies that the key + (257 INODE_REF 256) is no longer + the last key in the leaf, so it + returns with path->nodes[0] == + leaf X and path->slots[0] == N, + pointing to the new item with + key (257 INODE_REF 500) + + the loop iteration of run_dealloc_nocow() + does not break out the loop and continues + because the key referenced in the path + at path->nodes[0] and path->slots[0] is + for inode 257, its type is < BTRFS_EXTENT_DATA_KEY + and its offset (500) is less then our delalloc + range's end (8192) + + the item pointed by the path, an inode reference item, + is (incorrectly) interpreted as a file extent item and + we get an invalid extent type, leading to the BUG_ON(1): + + if (extent_type == BTRFS_FILE_EXTENT_REG || + extent_type == BTRFS_FILE_EXTENT_PREALLOC) { + (...) + } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) { + (...) + } else { + BUG_ON(1) + } + +The same can happen if a xattr is added concurrently and ends up having +a key with an offset smaller then the delalloc's range end. + +So fix this by skipping keys with a type smaller than +BTRFS_EXTENT_DATA_KEY. + +Signed-off-by: Filipe Manana <fdmanana@suse.com> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + fs/btrfs/inode.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -1203,8 +1203,14 @@ next_slot: + num_bytes = 0; + btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]); + +- if (found_key.objectid > ino || +- found_key.type > BTRFS_EXTENT_DATA_KEY || ++ if (found_key.objectid > ino) ++ break; ++ if (WARN_ON_ONCE(found_key.objectid < ino) || ++ found_key.type < BTRFS_EXTENT_DATA_KEY) { ++ path->slots[0]++; ++ goto next_slot; ++ } ++ if (found_key.type > BTRFS_EXTENT_DATA_KEY || + found_key.offset > end) + break; + diff --git a/patches/crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch b/patches/crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch new file mode 100644 index 0000000..115ef04 --- /dev/null +++ b/patches/crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch @@ -0,0 +1,51 @@ +From 4afa5f9617927453ac04b24b584f6c718dfb4f45 Mon Sep 17 00:00:00 2001 +From: Herbert Xu <herbert@gondor.apana.org.au> +Date: Sun, 1 Nov 2015 17:11:19 +0800 +Subject: crypto: algif_hash - Only export and import on sockets with data + +commit 4afa5f9617927453ac04b24b584f6c718dfb4f45 upstream. + +The hash_accept call fails to work on sockets that have not received +any data. For some algorithm implementations it may cause crashes. + +This patch fixes this by ensuring that we only export and import on +sockets that have received data. + +Reported-by: Harsh Jain <harshjain.prof@gmail.com> +Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> +Tested-by: Stephan Mueller <smueller@chronox.de> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + crypto/algif_hash.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +--- a/crypto/algif_hash.c ++++ b/crypto/algif_hash.c +@@ -192,9 +192,14 @@ static int hash_accept(struct socket *so + struct sock *sk2; + struct alg_sock *ask2; + struct hash_ctx *ctx2; ++ bool more; + int err; + +- err = crypto_ahash_export(req, state); ++ lock_sock(sk); ++ more = ctx->more; ++ err = more ? crypto_ahash_export(req, state) : 0; ++ release_sock(sk); ++ + if (err) + return err; + +@@ -205,7 +210,10 @@ static int hash_accept(struct socket *so + sk2 = newsock->sk; + ask2 = alg_sk(sk2); + ctx2 = ask2->private; +- ctx2->more = 1; ++ ctx2->more = more; ++ ++ if (!more) ++ return err; + + err = crypto_ahash_import(&ctx2->req, state); + if (err) { diff --git a/patches/devres-fix-a-for-loop-bounds-check.patch b/patches/devres-fix-a-for-loop-bounds-check.patch new file mode 100644 index 0000000..1249426 --- /dev/null +++ b/patches/devres-fix-a-for-loop-bounds-check.patch @@ -0,0 +1,32 @@ +From 1f35d04a02a652f14566f875aef3a6f2af4cb77b Mon Sep 17 00:00:00 2001 +From: Dan Carpenter <dan.carpenter@oracle.com> +Date: Mon, 21 Sep 2015 19:21:51 +0300 +Subject: devres: fix a for loop bounds check + +commit 1f35d04a02a652f14566f875aef3a6f2af4cb77b upstream. + +The iomap[] array has PCIM_IOMAP_MAX (6) elements and not +DEVICE_COUNT_RESOURCE (16). This bug was found using a static checker. +It may be that the "if (!(mask & (1 << i)))" check means we never +actually go past the end of the array in real life. + +Fixes: ec04b075843d ('iomap: implement pcim_iounmap_regions()') +Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> +Acked-by: Tejun Heo <tj@kernel.org> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + lib/devres.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/lib/devres.c ++++ b/lib/devres.c +@@ -390,7 +390,7 @@ void pcim_iounmap_regions(struct pci_dev + if (!iomap) + return; + +- for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) { ++ for (i = 0; i < PCIM_IOMAP_MAX; i++) { + if (!(mask & (1 << i))) + continue; + diff --git a/patches/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch b/patches/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch new file mode 100644 index 0000000..a74e81a --- /dev/null +++ b/patches/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch @@ -0,0 +1,102 @@ +From 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 Mon Sep 17 00:00:00 2001 +From: Daeho Jeong <daeho.jeong@samsung.com> +Date: Sun, 18 Oct 2015 17:02:56 -0400 +Subject: ext4, jbd2: ensure entering into panic after recording an error in + superblock + +commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream. + +If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the +journaling will be aborted first and the error number will be recorded +into JBD2 superblock and, finally, the system will enter into the +panic state in "errors=panic" option. But, in the rare case, this +sequence is little twisted like the below figure and it will happen +that the system enters into panic state, which means the system reset +in mobile environment, before completion of recording an error in the +journal superblock. In this case, e2fsck cannot recognize that the +filesystem failure occurred in the previous run and the corruption +wouldn't be fixed. + +Task A Task B +ext4_handle_error() +-> jbd2_journal_abort() + -> __journal_abort_soft() + -> __jbd2_journal_abort_hard() + | -> journal->j_flags |= JBD2_ABORT; + | + | __ext4_abort() + | -> jbd2_journal_abort() + | | -> __journal_abort_soft() + | | -> if (journal->j_flags & JBD2_ABORT) + | | return; + | -> panic() + | + -> jbd2_journal_update_sb_errno() + +Tested-by: Hobin Woo <hobin.woo@samsung.com> +Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com> +Signed-off-by: Theodore Ts'o <tytso@mit.edu> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + fs/ext4/super.c | 12 ++++++++++-- + fs/jbd2/journal.c | 6 +++++- + include/linux/jbd2.h | 1 + + 3 files changed, 16 insertions(+), 3 deletions(-) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -483,9 +483,13 @@ static void ext4_handle_error(struct sup + ext4_msg(sb, KERN_CRIT, "Remounting filesystem read-only"); + sb->s_flags |= MS_RDONLY; + } +- if (test_opt(sb, ERRORS_PANIC)) ++ if (test_opt(sb, ERRORS_PANIC)) { ++ if (EXT4_SB(sb)->s_journal && ++ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR)) ++ return; + panic("EXT4-fs (device %s): panic forced after error\n", + sb->s_id); ++ } + } + + void __ext4_error(struct super_block *sb, const char *function, +@@ -659,8 +663,12 @@ void __ext4_abort(struct super_block *sb + jbd2_journal_abort(EXT4_SB(sb)->s_journal, -EIO); + save_error_info(sb, function, line); + } +- if (test_opt(sb, ERRORS_PANIC)) ++ if (test_opt(sb, ERRORS_PANIC)) { ++ if (EXT4_SB(sb)->s_journal && ++ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR)) ++ return; + panic("EXT4-fs panic from previous error\n"); ++ } + } + + void ext4_msg(struct super_block *sb, const char *prefix, const char *fmt, ...) +--- a/fs/jbd2/journal.c ++++ b/fs/jbd2/journal.c +@@ -1921,8 +1921,12 @@ static void __journal_abort_soft (journa + + __jbd2_journal_abort_hard(journal); + +- if (errno) ++ if (errno) { + jbd2_journal_update_sb_errno(journal); ++ write_lock(&journal->j_state_lock); ++ journal->j_flags |= JBD2_REC_ERR; ++ write_unlock(&journal->j_state_lock); ++ } + } + + /** +--- a/include/linux/jbd2.h ++++ b/include/linux/jbd2.h +@@ -954,6 +954,7 @@ struct journal_s + #define JBD2_ABORT_ON_SYNCDATA_ERR 0x040 /* Abort the journal on file + * data write error in ordered + * mode */ ++#define JBD2_REC_ERR 0x080 /* The errno in the sb has been recorded */ + + /* + * Function declarations for the journaling transaction and buffer diff --git a/patches/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch b/patches/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch new file mode 100644 index 0000000..df8fdb3 --- /dev/null +++ b/patches/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch @@ -0,0 +1,68 @@ +From 100ceb66d5c40cc0c7018e06a9474302470be73c Mon Sep 17 00:00:00 2001 +From: Stefan Richter <stefanr@s5r6.in-berlin.de> +Date: Tue, 3 Nov 2015 01:46:21 +0100 +Subject: firewire: ohci: fix JMicron JMB38x IT context discovery + +commit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream. + +Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo +controllers: Often or even most of the time, the controller is +initialized with the message "added OHCI v1.10 device as card 0, 4 IR + +0 IT contexts, quirks 0x10". With 0 isochronous transmit DMA contexts +(IT contexts), applications like audio output are impossible. + +However, OHCI-1394 demands that at least 4 IT contexts are implemented +by the link layer controller, and indeed JMicron JMB38x do implement +four of them. Only their IsoXmitIntMask register is unreliable at early +access. + +With my own JMB381 single function controller I found: + - I can reproduce the problem with a lower probability than Craig's. + - If I put a loop around the section which clears and reads + IsoXmitIntMask, then either the first or the second attempt will + return the correct initial mask of 0x0000000f. I never encountered + a case of needing more than a second attempt. + - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet) + before the first write, the subsequent read will return the correct + result. + - If I merely ignore a wrong read result and force the known real + result, later isochronous transmit DMA usage works just fine. + +So let's just fix this chip bug up by the latter method. Tested with +JMB381 on kernel 3.13 and 4.3. + +Since OHCI-1394 generally requires 4 IT contexts at a minium, this +workaround is simply applied whenever the initial read of IsoXmitIntMask +returns 0, regardless whether it's a JMicron chip or not. I never heard +of this issue together with any other chip though. + +I am not 100% sure that this fix works on the OHCI-1394 part of JMB380 +and JMB388 combo controllers exactly the same as on the JMB381 single- +function controller, but so far I haven't had a chance to let an owner +of a combo chip run a patched kernel. + +Strangely enough, IsoRecvIntMask is always reported correctly, even +though it is probed right before IsoXmitIntMask. + +Reported-by: Clifford Dunn +Reported-by: Craig Moore <craig.moore@qenos.com> +Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/firewire/ohci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/firewire/ohci.c ++++ b/drivers/firewire/ohci.c +@@ -3620,6 +3620,11 @@ static int __devinit pci_probe(struct pc + + reg_write(ohci, OHCI1394_IsoXmitIntMaskSet, ~0); + ohci->it_context_support = reg_read(ohci, OHCI1394_IsoXmitIntMaskSet); ++ /* JMicron JMB38x often shows 0 at first read, just ignore it */ ++ if (!ohci->it_context_support) { ++ ohci_notice(ohci, "overriding IsoXmitIntMask\n"); ++ ohci->it_context_support = 0xf; ++ } + reg_write(ohci, OHCI1394_IsoXmitIntMaskClear, ~0); + ohci->it_context_mask = ohci->it_context_support; + ohci->n_it = hweight32(ohci->it_context_mask); diff --git a/patches/fs-cache-don-t-override-netfs-s-primary_index-if-registering-failed.patch b/patches/fs-cache-don-t-override-netfs-s-primary_index-if-registering-failed.patch new file mode 100644 index 0000000..93df0dc --- /dev/null +++ b/patches/fs-cache-don-t-override-netfs-s-primary_index-if-registering-failed.patch @@ -0,0 +1,88 @@ +From b130ed5998e62879a66bad08931a2b5e832da95c Mon Sep 17 00:00:00 2001 +From: Kinglong Mee <kinglongmee@gmail.com> +Date: Wed, 4 Nov 2015 15:20:24 +0000 +Subject: FS-Cache: Don't override netfs's primary_index if registering failed + +commit b130ed5998e62879a66bad08931a2b5e832da95c upstream. + +Only override netfs->primary_index when registering success. + +Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> +Signed-off-by: David Howells <dhowells@redhat.com> +Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> +[lizf: Backported to 3.4: there are no n_active and flags in primary_index] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + fs/fscache/netfs.c | 31 +++++++++++++++---------------- + 1 file changed, 15 insertions(+), 16 deletions(-) + +--- a/fs/fscache/netfs.c ++++ b/fs/fscache/netfs.c +@@ -22,6 +22,7 @@ static LIST_HEAD(fscache_netfs_list); + int __fscache_register_netfs(struct fscache_netfs *netfs) + { + struct fscache_netfs *ptr; ++ struct fscache_cookie *cookie; + int ret; + + _enter("{%s}", netfs->name); +@@ -29,24 +30,23 @@ int __fscache_register_netfs(struct fsca + INIT_LIST_HEAD(&netfs->link); + + /* allocate a cookie for the primary index */ +- netfs->primary_index = +- kmem_cache_zalloc(fscache_cookie_jar, GFP_KERNEL); ++ cookie = kmem_cache_zalloc(fscache_cookie_jar, GFP_KERNEL); + +- if (!netfs->primary_index) { ++ if (!cookie) { + _leave(" = -ENOMEM"); + return -ENOMEM; + } + + /* initialise the primary index cookie */ +- atomic_set(&netfs->primary_index->usage, 1); +- atomic_set(&netfs->primary_index->n_children, 0); ++ atomic_set(&cookie->usage, 1); ++ atomic_set(&cookie->n_children, 0); + +- netfs->primary_index->def = &fscache_fsdef_netfs_def; +- netfs->primary_index->parent = &fscache_fsdef_index; +- netfs->primary_index->netfs_data = netfs; ++ cookie->def = &fscache_fsdef_netfs_def; ++ cookie->parent = &fscache_fsdef_index; ++ cookie->netfs_data = netfs; + +- spin_lock_init(&netfs->primary_index->lock); +- INIT_HLIST_HEAD(&netfs->primary_index->backing_objects); ++ spin_lock_init(&cookie->lock); ++ INIT_HLIST_HEAD(&cookie->backing_objects); + + /* check the netfs type is not already present */ + down_write(&fscache_addremove_sem); +@@ -57,9 +57,10 @@ int __fscache_register_netfs(struct fsca + goto already_registered; + } + +- atomic_inc(&netfs->primary_index->parent->usage); +- atomic_inc(&netfs->primary_index->parent->n_children); ++ atomic_inc(&cookie->parent->usage); ++ atomic_inc(&cookie->parent->n_children); + ++ netfs->primary_index = cookie; + list_add(&netfs->link, &fscache_netfs_list); + ret = 0; + +@@ -69,10 +70,8 @@ int __fscache_register_netfs(struct fsca + already_registered: + up_write(&fscache_addremove_sem); + +- if (ret < 0) { +- kmem_cache_free(fscache_cookie_jar, netfs->primary_index); +- netfs->primary_index = NULL; +- } ++ if (ret < 0) ++ kmem_cache_free(fscache_cookie_jar, cookie); + + _leave(" = %d", ret); + return ret; diff --git a/patches/fs-cache-handle-a-write-to-the-page-immediately-beyond-the-eof-marker.patch b/patches/fs-cache-handle-a-write-to-the-page-immediately-beyond-the-eof-marker.patch new file mode 100644 index 0000000..b5cfb48 --- /dev/null +++ b/patches/fs-cache-handle-a-write-to-the-page-immediately-beyond-the-eof-marker.patch @@ -0,0 +1,154 @@ +From 102f4d900c9c8f5ed89ae4746d493fe3ebd7ba64 Mon Sep 17 00:00:00 2001 +From: David Howells <dhowells@redhat.com> +Date: Wed, 4 Nov 2015 15:20:42 +0000 +Subject: FS-Cache: Handle a write to the page immediately beyond the EOF + marker + +commit 102f4d900c9c8f5ed89ae4746d493fe3ebd7ba64 upstream. + +Handle a write being requested to the page immediately beyond the EOF +marker on a cache object. Currently this gets an assertion failure in +CacheFiles because the EOF marker is used there to encode information about +a partial page at the EOF - which could lead to an unknown blank spot in +the file if we extend the file over it. + +The problem is actually in fscache where we check the index of the page +being written against store_limit. store_limit is set to the number of +pages that we're allowed to store by fscache_set_store_limit() - which +means it's one more than the index of the last page we're allowed to store. +The problem is that we permit writing to a page with an index _equal_ to +the store limit - when we should reject that case. + +Whilst we're at it, change the triggered assertion in CacheFiles to just +return -ENOBUFS instead. + +The assertion failure looks something like this: + +CacheFiles: Assertion failed +1000 < 7b1 is false +------------[ cut here ]------------ +kernel BUG at fs/cachefiles/rdwr.c:962! +... +RIP: 0010:[<ffffffffa02c9e83>] [<ffffffffa02c9e83>] cachefiles_write_page+0x273/0x2d0 [cachefiles] + +Signed-off-by: David Howells <dhowells@redhat.com> +Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> +[lizf: Backported to 3.4: adjust context] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + fs/cachefiles/rdwr.c | 80 ++++++++++++++++++++++++++++----------------------- + fs/fscache/page.c | 2 - + 2 files changed, 45 insertions(+), 37 deletions(-) + +--- a/fs/cachefiles/rdwr.c ++++ b/fs/cachefiles/rdwr.c +@@ -914,6 +914,15 @@ int cachefiles_write_page(struct fscache + cache = container_of(object->fscache.cache, + struct cachefiles_cache, cache); + ++ pos = (loff_t)page->index << PAGE_SHIFT; ++ ++ /* We mustn't write more data than we have, so we have to beware of a ++ * partial page at EOF. ++ */ ++ eof = object->fscache.store_limit_l; ++ if (pos >= eof) ++ goto error; ++ + /* write the page to the backing filesystem and let it store it in its + * own time */ + dget(object->backer); +@@ -922,47 +931,46 @@ int cachefiles_write_page(struct fscache + cache->cache_cred); + if (IS_ERR(file)) { + ret = PTR_ERR(file); +- } else { ++ goto error_2; ++ } ++ if (!file->f_op->write) { + ret = -EIO; +- if (file->f_op->write) { +- pos = (loff_t) page->index << PAGE_SHIFT; +- +- /* we mustn't write more data than we have, so we have +- * to beware of a partial page at EOF */ +- eof = object->fscache.store_limit_l; +- len = PAGE_SIZE; +- if (eof & ~PAGE_MASK) { +- ASSERTCMP(pos, <, eof); +- if (eof - pos < PAGE_SIZE) { +- _debug("cut short %llx to %llx", +- pos, eof); +- len = eof - pos; +- ASSERTCMP(pos + len, ==, eof); +- } +- } +- +- data = kmap(page); +- old_fs = get_fs(); +- set_fs(KERNEL_DS); +- ret = file->f_op->write( +- file, (const void __user *) data, len, &pos); +- set_fs(old_fs); +- kunmap(page); +- if (ret != len) +- ret = -EIO; +- } +- fput(file); ++ goto error_2; + } + +- if (ret < 0) { +- if (ret == -EIO) +- cachefiles_io_error_obj( +- object, "Write page to backing file failed"); +- ret = -ENOBUFS; ++ len = PAGE_SIZE; ++ if (eof & ~PAGE_MASK) { ++ if (eof - pos < PAGE_SIZE) { ++ _debug("cut short %llx to %llx", ++ pos, eof); ++ len = eof - pos; ++ ASSERTCMP(pos + len, ==, eof); ++ } + } + +- _leave(" = %d", ret); +- return ret; ++ data = kmap(page); ++ old_fs = get_fs(); ++ set_fs(KERNEL_DS); ++ ret = file->f_op->write( ++ file, (const void __user *) data, len, &pos); ++ set_fs(old_fs); ++ kunmap(page); ++ fput(file); ++ if (ret != len) ++ goto error_eio; ++ ++ _leave(" = 0"); ++ return 0; ++ ++error_eio: ++ ret = -EIO; ++error_2: ++ if (ret == -EIO) ++ cachefiles_io_error_obj(object, ++ "Write page to backing file failed"); ++error: ++ _leave(" = -ENOBUFS [%d]", ret); ++ return -ENOBUFS; + } + + /* +--- a/fs/fscache/page.c ++++ b/fs/fscache/page.c +@@ -676,7 +676,7 @@ static void fscache_write_op(struct fsca + goto superseded; + page = results[0]; + _debug("gang %d [%lx]", n, page->index); +- if (page->index > op->store_limit) { ++ if (page->index >= op->store_limit) { + fscache_stat(&fscache_n_store_pages_over_limit); + goto superseded; + } diff --git a/patches/fs-cache-increase-reference-of-parent-after-registering-netfs-success.patch b/patches/fs-cache-increase-reference-of-parent-after-registering-netfs-success.patch new file mode 100644 index 0000000..6cee7e4 --- /dev/null +++ b/patches/fs-cache-increase-reference-of-parent-after-registering-netfs-success.patch @@ -0,0 +1,57 @@ +From 86108c2e34a26e4bec3c6ddb23390bf8cedcf391 Mon Sep 17 00:00:00 2001 +From: Kinglong Mee <kinglongmee@gmail.com> +Date: Wed, 4 Nov 2015 15:20:15 +0000 +Subject: FS-Cache: Increase reference of parent after registering, netfs + success + +commit 86108c2e34a26e4bec3c6ddb23390bf8cedcf391 upstream. + +If netfs exist, fscache should not increase the reference of parent's +usage and n_children, otherwise, never be decreased. + +v2: thanks David's suggest, + move increasing reference of parent if success + use kmem_cache_free() freeing primary_index directly + +v3: don't move "netfs->primary_index->parent = &fscache_fsdef_index;" + +Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> +Signed-off-by: David Howells <dhowells@redhat.com> +Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + fs/fscache/netfs.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +--- a/fs/fscache/netfs.c ++++ b/fs/fscache/netfs.c +@@ -45,9 +45,6 @@ int __fscache_register_netfs(struct fsca + netfs->primary_index->parent = &fscache_fsdef_index; + netfs->primary_index->netfs_data = netfs; + +- atomic_inc(&netfs->primary_index->parent->usage); +- atomic_inc(&netfs->primary_index->parent->n_children); +- + spin_lock_init(&netfs->primary_index->lock); + INIT_HLIST_HEAD(&netfs->primary_index->backing_objects); + +@@ -60,6 +57,9 @@ int __fscache_register_netfs(struct fsca + goto already_registered; + } + ++ atomic_inc(&netfs->primary_index->parent->usage); ++ atomic_inc(&netfs->primary_index->parent->n_children); ++ + list_add(&netfs->link, &fscache_netfs_list); + ret = 0; + +@@ -70,8 +70,7 @@ already_registered: + up_write(&fscache_addremove_sem); + + if (ret < 0) { +- netfs->primary_index->parent = NULL; +- __fscache_cookie_put(netfs->primary_index); ++ kmem_cache_free(fscache_cookie_jar, netfs->primary_index); + netfs->primary_index = NULL; + } + diff --git a/patches/hid-core-avoid-uninitialized-buffer-access.patch b/patches/hid-core-avoid-uninitialized-buffer-access.patch new file mode 100644 index 0000000..efee385 --- /dev/null +++ b/patches/hid-core-avoid-uninitialized-buffer-access.patch @@ -0,0 +1,36 @@ +From 79b568b9d0c7c5d81932f4486d50b38efdd6da6d Mon Sep 17 00:00:00 2001 +From: Richard Purdie <richard.purdie@linuxfoundation.org> +Date: Fri, 18 Sep 2015 16:31:33 -0700 +Subject: HID: core: Avoid uninitialized buffer access + +commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream. + +hid_connect adds various strings to the buffer but they're all +conditional. You can find circumstances where nothing would be written +to it but the kernel will still print the supposedly empty buffer with +printk. This leads to corruption on the console/in the logs. + +Ensure buf is initialized to an empty string. + +Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> +[dvhart: Initialize string to "" rather than assign buf[0] = NULL;] +Cc: Jiri Kosina <jikos@kernel.org> +Cc: linux-input@vger.kernel.org +Signed-off-by: Darren Hart <dvhart@linux.intel.com> +Signed-off-by: Jiri Kosina <jkosina@suse.cz> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/hid/hid-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/hid/hid-core.c ++++ b/drivers/hid/hid-core.c +@@ -1301,7 +1301,7 @@ int hid_connect(struct hid_device *hdev, + "Multi-Axis Controller" + }; + const char *type, *bus; +- char buf[64]; ++ char buf[64] = ""; + unsigned int i; + int len; + int ret; diff --git a/patches/iommu-vt-d-fix-atsr-handling-for-root-complex-integrated-endpoints.patch b/patches/iommu-vt-d-fix-atsr-handling-for-root-complex-integrated-endpoints.patch new file mode 100644 index 0000000..9f7750b --- /dev/null +++ b/patches/iommu-vt-d-fix-atsr-handling-for-root-complex-integrated-endpoints.patch @@ -0,0 +1,34 @@ +From d14053b3c714178525f22660e6aaf41263d00056 Mon Sep 17 00:00:00 2001 +From: David Woodhouse <David.Woodhouse@intel.com> +Date: Thu, 15 Oct 2015 09:28:06 +0100 +Subject: iommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +commit d14053b3c714178525f22660e6aaf41263d00056 upstream. + +The VT-d specification says that "Software must enable ATS on endpoint +devices behind a Root Port only if the Root Port is reported as +supporting ATS transactions." + +We walk up the tree to find a Root Port, but for integrated devices we +don't find one — we get to the host bridge. In that case we *should* +allow ATS. Currently we don't, which means that we are incorrectly +failing to use ATS for the integrated graphics. Fix that. + +We should never break out of this loop "naturally" with bus==NULL, +since we'll always find bridge==NULL in that case (and now return 1). + +So remove the check for (!bridge) after the loop, since it can never +happen. If it did, it would be worthy of a BUG_ON(!bridge). But since +it'll oops anyway in that case, that'll do just as well. + +Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> +[lizf: Backported to 3.4: + - adjust context + - drop the last part of the changes of the patch] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + 0 files changed + diff --git a/patches/ipv6-fix-tunnel-error-handling.patch b/patches/ipv6-fix-tunnel-error-handling.patch new file mode 100644 index 0000000..ad96b65 --- /dev/null +++ b/patches/ipv6-fix-tunnel-error-handling.patch @@ -0,0 +1,49 @@ +From ebac62fe3d24c0ce22dd83afa7b07d1a2aaef44d Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Michal=20Kube=C4=8Dek?= <mkubecek@suse.cz> +Date: Tue, 3 Nov 2015 08:51:07 +0100 +Subject: ipv6: fix tunnel error handling + +commit ebac62fe3d24c0ce22dd83afa7b07d1a2aaef44d upstream. + +Both tunnel6_protocol and tunnel46_protocol share the same error +handler, tunnel6_err(), which traverses through tunnel6_handlers list. +For ipip6 tunnels, we need to traverse tunnel46_handlers as we do e.g. +in tunnel46_rcv(). Current code can generate an ICMPv6 error message +with an IPv4 packet embedded in it. + +Fixes: 73d605d1abbd ("[IPSEC]: changing API of xfrm6_tunnel_register") +Signed-off-by: Michal Kubecek <mkubecek@suse.cz> +Signed-off-by: David S. Miller <davem@davemloft.net> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + net/ipv6/tunnel6.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/net/ipv6/tunnel6.c ++++ b/net/ipv6/tunnel6.c +@@ -145,6 +145,16 @@ static void tunnel6_err(struct sk_buff * + break; + } + ++static void tunnel46_err(struct sk_buff *skb, struct inet6_skb_parm *opt, ++ u8 type, u8 code, int offset, __be32 info) ++{ ++ struct xfrm6_tunnel *handler; ++ ++ for_each_tunnel_rcu(tunnel46_handlers, handler) ++ if (!handler->err_handler(skb, opt, type, code, offset, info)) ++ break; ++} ++ + static const struct inet6_protocol tunnel6_protocol = { + .handler = tunnel6_rcv, + .err_handler = tunnel6_err, +@@ -153,7 +163,7 @@ static const struct inet6_protocol tunne + + static const struct inet6_protocol tunnel46_protocol = { + .handler = tunnel46_rcv, +- .err_handler = tunnel6_err, ++ .err_handler = tunnel46_err, + .flags = INET6_PROTO_NOPOLICY|INET6_PROTO_FINAL, + }; + diff --git a/patches/mac80211-fix-driver-rssi-event-calculations.patch b/patches/mac80211-fix-driver-rssi-event-calculations.patch new file mode 100644 index 0000000..d74db08 --- /dev/null +++ b/patches/mac80211-fix-driver-rssi-event-calculations.patch @@ -0,0 +1,30 @@ +From 8ec6d97871f37e4743678ea4a455bd59580aa0f4 Mon Sep 17 00:00:00 2001 +From: Johannes Berg <johannes.berg@intel.com> +Date: Fri, 28 Aug 2015 10:52:53 +0200 +Subject: mac80211: fix driver RSSI event calculations + +commit 8ec6d97871f37e4743678ea4a455bd59580aa0f4 upstream. + +The ifmgd->ave_beacon_signal value cannot be taken as is for +comparisons, it must be divided by since it's represented +like that for better accuracy of the EWMA calculations. This +would lead to invalid driver RSSI events. Fix the used value. + +Fixes: 615f7b9bb1f8 ("mac80211: add driver RSSI threshold events") +Signed-off-by: Johannes Berg <johannes.berg@intel.com> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + net/mac80211/mlme.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mac80211/mlme.c ++++ b/net/mac80211/mlme.c +@@ -2384,7 +2384,7 @@ static void ieee80211_rx_mgmt_beacon(str + + if (ifmgd->rssi_min_thold != ifmgd->rssi_max_thold && + ifmgd->count_beacon_signal >= IEEE80211_SIGNAL_AVE_MIN_COUNT) { +- int sig = ifmgd->ave_beacon_signal; ++ int sig = ifmgd->ave_beacon_signal / 16; + int last_sig = ifmgd->last_ave_beacon_signal; + + /* diff --git a/patches/megaraid_sas-do-not-use-page_size-for-max_sectors.patch b/patches/megaraid_sas-do-not-use-page_size-for-max_sectors.patch new file mode 100644 index 0000000..a7e3db2 --- /dev/null +++ b/patches/megaraid_sas-do-not-use-page_size-for-max_sectors.patch @@ -0,0 +1,45 @@ +From 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 Mon Sep 17 00:00:00 2001 +From: "sumit.saxena@avagotech.com" <sumit.saxena@avagotech.com> +Date: Thu, 15 Oct 2015 13:40:04 +0530 +Subject: megaraid_sas: Do not use PAGE_SIZE for max_sectors + +commit 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 upstream. + +Do not use PAGE_SIZE marco to calculate max_sectors per I/O +request. Driver code assumes PAGE_SIZE will be always 4096 which can +lead to wrongly calculated value if PAGE_SIZE is not 4096. This issue +was reported in Ubuntu Bugzilla Bug #1475166. + +Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com> +Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com> +Reviewed-by: Tomas Henzl <thenzl@redhat.com> +Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> +Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/scsi/megaraid/megaraid_sas.h | 2 ++ + drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- + 2 files changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/scsi/megaraid/megaraid_sas.h ++++ b/drivers/scsi/megaraid/megaraid_sas.h +@@ -300,6 +300,8 @@ enum MR_EVT_ARGS { + MR_EVT_ARGS_GENERIC, + }; + ++ ++#define SGE_BUFFER_SIZE 4096 + /* + * define constants for device list query options + */ +--- a/drivers/scsi/megaraid/megaraid_sas_base.c ++++ b/drivers/scsi/megaraid/megaraid_sas_base.c +@@ -3582,7 +3582,7 @@ static int megasas_init_fw(struct megasa + } + + instance->max_sectors_per_req = instance->max_num_sge * +- PAGE_SIZE / 512; ++ SGE_BUFFER_SIZE / 512; + if (tmp_sectors && (instance->max_sectors_per_req > tmp_sectors)) + instance->max_sectors_per_req = tmp_sectors; + diff --git a/patches/megaraid_sas-smap-restriction-do-not-access-user-memory-from-ioctl-code.patch b/patches/megaraid_sas-smap-restriction-do-not-access-user-memory-from-ioctl-code.patch new file mode 100644 index 0000000..a3b02ae --- /dev/null +++ b/patches/megaraid_sas-smap-restriction-do-not-access-user-memory-from-ioctl-code.patch @@ -0,0 +1,51 @@ +From 323c4a02c631d00851d8edc4213c4d184ef83647 Mon Sep 17 00:00:00 2001 +From: "sumit.saxena@avagotech.com" <sumit.saxena@avagotech.com> +Date: Thu, 15 Oct 2015 13:40:54 +0530 +Subject: megaraid_sas : SMAP restriction--do not access user memory from IOCTL + code + +commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream. + +This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit +OS. Do not access user memory from kernel code. The SMAP bit restricts +accessing user memory from kernel code. + +Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com> +Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com> +Reviewed-by: Tomas Henzl <thenzl@redhat.com> +Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/scsi/megaraid/megaraid_sas_base.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +--- a/drivers/scsi/megaraid/megaraid_sas_base.c ++++ b/drivers/scsi/megaraid/megaraid_sas_base.c +@@ -5014,6 +5014,9 @@ static int megasas_mgmt_compat_ioctl_fw( + int i; + int error = 0; + compat_uptr_t ptr; ++ unsigned long local_raw_ptr; ++ u32 local_sense_off; ++ u32 local_sense_len; + + if (clear_user(ioc, sizeof(*ioc))) + return -EFAULT; +@@ -5031,9 +5034,15 @@ static int megasas_mgmt_compat_ioctl_fw( + * sense_len is not null, so prepare the 64bit value under + * the same condition. + */ +- if (ioc->sense_len) { ++ if (get_user(local_raw_ptr, ioc->frame.raw) || ++ get_user(local_sense_off, &ioc->sense_off) || ++ get_user(local_sense_len, &ioc->sense_len)) ++ return -EFAULT; ++ ++ ++ if (local_sense_len) { + void __user **sense_ioc_ptr = +- (void __user **)(ioc->frame.raw + ioc->sense_off); ++ (void __user **)((u8*)local_raw_ptr + local_sense_off); + compat_uptr_t *sense_cioc_ptr = + (compat_uptr_t *)(cioc->frame.raw + cioc->sense_off); + if (get_user(ptr, sense_cioc_ptr) || diff --git a/patches/mips-atomic-fix-comment-describing-atomic64_add_unless-s-return-value.patch b/patches/mips-atomic-fix-comment-describing-atomic64_add_unless-s-return-value.patch new file mode 100644 index 0000000..5ba9454 --- /dev/null +++ b/patches/mips-atomic-fix-comment-describing-atomic64_add_unless-s-return-value.patch @@ -0,0 +1,27 @@ +From f25319d2cb439249a6859f53ad42ffa332b0acba Mon Sep 17 00:00:00 2001 +From: Ralf Baechle <ralf@linux-mips.org> +Date: Fri, 16 Oct 2015 23:09:57 +0200 +Subject: MIPS: atomic: Fix comment describing atomic64_add_unless's return + value. + +commit f25319d2cb439249a6859f53ad42ffa332b0acba upstream. + +Signed-off-by: Ralf Baechle <ralf@linux-mips.org> +Fixes: f24219b4e90cf70ec4a211b17fbabc725a0ddf3c +(cherry picked from commit f0a232cde7be18a207fd057dd79bbac8a0a45dec) +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + arch/mips/include/asm/atomic.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/mips/include/asm/atomic.h ++++ b/arch/mips/include/asm/atomic.h +@@ -679,7 +679,7 @@ static __inline__ long atomic64_sub_if_p + * @u: ...unless v is equal to u. + * + * Atomically adds @a to @v, so long as it was not @u. +- * Returns the old value of @v. ++ * Returns true iff @v was not @u. + */ + static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) + { diff --git a/patches/mtd-mtdpart-fix-add_mtd_partitions-error-path.patch b/patches/mtd-mtdpart-fix-add_mtd_partitions-error-path.patch new file mode 100644 index 0000000..5a35bf6 --- /dev/null +++ b/patches/mtd-mtdpart-fix-add_mtd_partitions-error-path.patch @@ -0,0 +1,33 @@ +From e5bae86797141e4a95e42d825f737cb36d7b8c37 Mon Sep 17 00:00:00 2001 +From: Boris BREZILLON <boris.brezillon@free-electrons.com> +Date: Thu, 30 Jul 2015 12:18:03 +0200 +Subject: mtd: mtdpart: fix add_mtd_partitions error path + +commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream. + +If we fail to allocate a partition structure in the middle of the partition +creation process, the already allocated partitions are never removed, which +means they are still present in the partition list and their resources are +never freed. + +Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> +Signed-off-by: Brian Norris <computersforpeace@gmail.com> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/mtd/mtdpart.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/mtd/mtdpart.c ++++ b/drivers/mtd/mtdpart.c +@@ -632,8 +632,10 @@ int add_mtd_partitions(struct mtd_info * + + for (i = 0; i < nbparts; i++) { + slave = allocate_partition(master, parts + i, i, cur_offset); +- if (IS_ERR(slave)) ++ if (IS_ERR(slave)) { ++ del_mtd_partitions(master); + return PTR_ERR(slave); ++ } + + mutex_lock(&mtd_partitions_mutex); + list_add(&slave->list, &mtd_partitions); diff --git a/patches/mwifiex-fix-mwifiex_rdeeprom_read.patch b/patches/mwifiex-fix-mwifiex_rdeeprom_read.patch new file mode 100644 index 0000000..b5183f6 --- /dev/null +++ b/patches/mwifiex-fix-mwifiex_rdeeprom_read.patch @@ -0,0 +1,76 @@ +From 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter <dan.carpenter@oracle.com> +Date: Mon, 21 Sep 2015 19:19:53 +0300 +Subject: mwifiex: fix mwifiex_rdeeprom_read() + +commit 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 upstream. + +There were several bugs here. + +1) The done label was in the wrong place so we didn't copy any + information out when there was no command given. + +2) We were using PAGE_SIZE as the size of the buffer instead of + "PAGE_SIZE - pos". + +3) snprintf() returns the number of characters that would have been + printed if there were enough space. If there was not enough space + (and we had fixed the memory corruption bug #2) then it would result + in an information leak when we do simple_read_from_buffer(). I've + changed it to use scnprintf() instead. + +I also removed the initialization at the start of the function, because +I thought it made the code a little more clear. + +Fixes: 5e6e3a92b9a4 ('wireless: mwifiex: initial commit for Marvell mwifiex driver') +Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> +Acked-by: Amitkumar Karwar <akarwar@marvell.com> +Signed-off-by: Kalle Valo <kvalo@codeaurora.org> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/net/wireless/mwifiex/debugfs.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/drivers/net/wireless/mwifiex/debugfs.c ++++ b/drivers/net/wireless/mwifiex/debugfs.c +@@ -621,7 +621,7 @@ mwifiex_rdeeprom_read(struct file *file, + (struct mwifiex_private *) file->private_data; + unsigned long addr = get_zeroed_page(GFP_KERNEL); + char *buf = (char *) addr; +- int pos = 0, ret = 0, i; ++ int pos, ret, i; + u8 value[MAX_EEPROM_DATA]; + + if (!buf) +@@ -629,7 +629,7 @@ mwifiex_rdeeprom_read(struct file *file, + + if (saved_offset == -1) { + /* No command has been given */ +- pos += snprintf(buf, PAGE_SIZE, "0"); ++ pos = snprintf(buf, PAGE_SIZE, "0"); + goto done; + } + +@@ -638,17 +638,17 @@ mwifiex_rdeeprom_read(struct file *file, + (u16) saved_bytes, value); + if (ret) { + ret = -EINVAL; +- goto done; ++ goto out_free; + } + +- pos += snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes); ++ pos = snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes); + + for (i = 0; i < saved_bytes; i++) +- pos += snprintf(buf + strlen(buf), PAGE_SIZE, "%d ", value[i]); +- +- ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos); ++ pos += scnprintf(buf + pos, PAGE_SIZE - pos, "%d ", value[i]); + + done: ++ ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos); ++out_free: + free_page(addr); + return ret; + } diff --git a/patches/net-fix-a-race-in-dst_release.patch b/patches/net-fix-a-race-in-dst_release.patch new file mode 100644 index 0000000..5269469 --- /dev/null +++ b/patches/net-fix-a-race-in-dst_release.patch @@ -0,0 +1,33 @@ +From d69bbf88c8d0b367cf3e3a052f6daadf630ee566 Mon Sep 17 00:00:00 2001 +From: Eric Dumazet <edumazet@google.com> +Date: Mon, 9 Nov 2015 17:51:23 -0800 +Subject: net: fix a race in dst_release() + +commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 upstream. + +Only cpu seeing dst refcount going to 0 can safely +dereference dst->flags. + +Otherwise an other cpu might already have freed the dst. + +Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst") +Reported-by: Greg Thelen <gthelen@google.com> +Signed-off-by: Eric Dumazet <edumazet@google.com> +Signed-off-by: David S. Miller <davem@davemloft.net> +[lizf: Backported to 3.4: adjust context] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + net/core/dst.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/core/dst.c ++++ b/net/core/dst.c +@@ -272,7 +272,7 @@ void dst_release(struct dst_entry *dst) + + newrefcnt = atomic_dec_return(&dst->__refcnt); + WARN_ON(newrefcnt < 0); +- if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt) { ++ if (!newrefcnt && unlikely(dst->flags & DST_NOCACHE)) { + dst = dst_destroy(dst); + if (dst) + __dst_free(dst); diff --git a/patches/perf-fix-inherited-events-vs.-tracepoint-filters.patch b/patches/perf-fix-inherited-events-vs.-tracepoint-filters.patch new file mode 100644 index 0000000..8c34630 --- /dev/null +++ b/patches/perf-fix-inherited-events-vs.-tracepoint-filters.patch @@ -0,0 +1,51 @@ +From b71b437eedaed985062492565d9d421d975ae845 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra <peterz@infradead.org> +Date: Mon, 2 Nov 2015 10:50:51 +0100 +Subject: perf: Fix inherited events vs. tracepoint filters +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +commit b71b437eedaed985062492565d9d421d975ae845 upstream. + +Arnaldo reported that tracepoint filters seem to misbehave (ie. not +apply) on inherited events. + +The fix is obvious; filters are only set on the actual (parent) +event, use the normal pattern of using this parent event for filters. +This is safe because each child event has a reference to it. + +Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org> +Tested-by: Arnaldo Carvalho de Melo <acme@kernel.org> +Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> +Cc: Adrian Hunter <adrian.hunter@intel.com> +Cc: Arnaldo Carvalho de Melo <acme@redhat.com> +Cc: David Ahern <dsahern@gmail.com> +Cc: Frédéric Weisbecker <fweisbec@gmail.com> +Cc: Jiri Olsa <jolsa@kernel.org> +Cc: Jiri Olsa <jolsa@redhat.com> +Cc: Linus Torvalds <torvalds@linux-foundation.org> +Cc: Peter Zijlstra <peterz@infradead.org> +Cc: Steven Rostedt <rostedt@goodmis.org> +Cc: Thomas Gleixner <tglx@linutronix.de> +Cc: Wang Nan <wangnan0@huawei.com> +Link: http://lkml.kernel.org/r/20151102095051.GN17308@twins.programming.kicks-ass.net +Signed-off-by: Ingo Molnar <mingo@kernel.org> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + kernel/events/core.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -5366,6 +5366,10 @@ static int perf_tp_filter_match(struct p + { + void *record = data->raw->data; + ++ /* only top level events have filters set */ ++ if (event->parent) ++ event = event->parent; ++ + if (likely(!event->filter) || filter_match_preds(event->filter, record)) + return 1; + return 0; diff --git a/patches/recordmcount-fix-endianness-handling-bug-for-nop_mcount.patch b/patches/recordmcount-fix-endianness-handling-bug-for-nop_mcount.patch new file mode 100644 index 0000000..36e653e --- /dev/null +++ b/patches/recordmcount-fix-endianness-handling-bug-for-nop_mcount.patch @@ -0,0 +1,31 @@ +From c84da8b9ad3761eef43811181c7e896e9834b26b Mon Sep 17 00:00:00 2001 +From: libin <huawei.libin@huawei.com> +Date: Tue, 3 Nov 2015 08:58:47 +0800 +Subject: recordmcount: Fix endianness handling bug for nop_mcount + +commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream. + +In nop_mcount, shdr->sh_offset and welp->r_offset should handle +endianness properly, otherwise it will trigger Segmentation fault +if the recordmcount main and file.o have different endianness. + +Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com + +Signed-off-by: Li Bin <huawei.libin@huawei.com> +Signed-off-by: Steven Rostedt <rostedt@goodmis.org> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + scripts/recordmcount.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/scripts/recordmcount.h ++++ b/scripts/recordmcount.h +@@ -375,7 +375,7 @@ static void nop_mcount(Elf_Shdr const *c + + if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) { + if (make_nop) +- ret = make_nop((void *)ehdr, shdr->sh_offset + relp->r_offset); ++ ret = make_nop((void *)ehdr, _w(shdr->sh_offset) + _w(relp->r_offset)); + if (warn_on_notrace_sect && !once) { + printf("Section %s has mcount callers being ignored\n", + txtname); diff --git a/patches/revert-dm-mpath-fix-stalls-when-handling-invalid-ioctls.patch b/patches/revert-dm-mpath-fix-stalls-when-handling-invalid-ioctls.patch new file mode 100644 index 0000000..e951a90 --- /dev/null +++ b/patches/revert-dm-mpath-fix-stalls-when-handling-invalid-ioctls.patch @@ -0,0 +1,170 @@ +From 47796938c46b943d157ac8a6f9ed4e3b98b83cf4 Mon Sep 17 00:00:00 2001 +From: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> +Date: Thu, 29 Oct 2015 10:24:23 -0200 +Subject: Revert "dm mpath: fix stalls when handling invalid ioctls" + +commit 47796938c46b943d157ac8a6f9ed4e3b98b83cf4 upstream. + +This reverts commit a1989b330093578ea5470bea0a00f940c444c466. + +That commit introduced a regression at least for the case of the SG_IO ioctl() +running without CAP_SYS_RAWIO capability (e.g., unprivileged users) when there +are no active paths: the ioctl() fails with the ENOTTY errno immediately rather +than blocking due to queue_if_no_path until a path becomes active, for example. + +That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices +(qemu "-device scsi-block" [1], libvirt "<disk type='block' device='lun'>" [2]) +from multipath devices; which leads to SCSI/filesystem errors in such a guest. + +More general scenarios can hit that regression too. The following demonstration +employs a SG_IO ioctl() with a standard SCSI INQUIRY command for this objective +(some output & user changes omitted for brevity and comments added for clarity). + +Reverting that commit restores normal operation (queueing) in failing scenarios; +tested on linux-next (next-20151022). + +1) Test-case is based on sg_simple0 [3] (just SG_IO; remove SG_GET_VERSION_NUM) + + $ cat sg_simple0.c + ... see [3] ... + $ sed '/SG_GET_VERSION_NUM/,/}/d' sg_simple0.c > sgio_inquiry.c + $ gcc sgio_inquiry.c -o sgio_inquiry + +2) The ioctl() works fine with active paths present. + + # multipath -l 85ag56 + 85ag56 (...) dm-19 IBM ,2145 + size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw + |-+- policy='service-time 0' prio=0 status=active + | |- 8:0:11:0 sdz 65:144 active undef running + | `- 9:0:9:0 sdbf 67:144 active undef running + `-+- policy='service-time 0' prio=0 status=enabled + |- 8:0:12:0 sdae 65:224 active undef running + `- 9:0:12:0 sdbo 68:32 active undef running + + $ ./sgio_inquiry /dev/mapper/85ag56 + Some of the INQUIRY command's response: + IBM 2145 0000 + INQUIRY duration=0 millisecs, resid=0 + +3) The ioctl() fails with ENOTTY errno with _no_ active paths present, + for unprivileged users (rather than blocking due to queue_if_no_path). + + # for path in $(multipath -l 85ag56 | grep -o 'sd[a-z]\+'); \ + do multipathd -k"fail path $path"; done + + # multipath -l 85ag56 + 85ag56 (...) dm-19 IBM ,2145 + size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw + |-+- policy='service-time 0' prio=0 status=enabled + | |- 8:0:11:0 sdz 65:144 failed undef running + | `- 9:0:9:0 sdbf 67:144 failed undef running + `-+- policy='service-time 0' prio=0 status=enabled + |- 8:0:12:0 sdae 65:224 failed undef running + `- 9:0:12:0 sdbo 68:32 failed undef running + + $ ./sgio_inquiry /dev/mapper/85ag56 + sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device + +4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285); + it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl(). + + $ dmesg + <...> + [] device-mapper: multipath: Failing path 65:144. + [] device-mapper: multipath: Failing path 67:144. + [] device-mapper: multipath: Failing path 65:224. + [] device-mapper: multipath: Failing path 68:32. + [] sgio_inquiry: sending ioctl 2285 to a partition! + +5) The ioctl() only works if the SYS_CAP_RAWIO capability is present + (then queueing happens -- in this example, queue_if_no_path is set); + this is due to a conditional check in scsi_verify_blk_ioctl(). + + # capsh --drop=cap_sys_rawio -- -c './sgio_inquiry /dev/mapper/85ag56' + sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device + + # ./sgio_inquiry /dev/mapper/85ag56 & + [1] 72830 + + # cat /proc/72830/stack + [<c00000171c0df700>] 0xc00000171c0df700 + [<c000000000015934>] __switch_to+0x204/0x350 + [<c000000000152d4c>] msleep+0x5c/0x80 + [<c00000000077dfb0>] dm_blk_ioctl+0x70/0x170 + [<c000000000487c40>] blkdev_ioctl+0x2b0/0x9b0 + [<c0000000003128e4>] block_ioctl+0x64/0xd0 + [<c0000000002dd3b0>] do_vfs_ioctl+0x490/0x780 + [<c0000000002dd774>] SyS_ioctl+0xd4/0xf0 + [<c000000000009358>] system_call+0x38/0xd0 + +6) This is the function call chain exercised in this analysis: + +SYSCALL_DEFINE3(ioctl, <...>) @ fs/ioctl.c + -> do_vfs_ioctl() + -> vfs_ioctl() + ... + error = filp->f_op->unlocked_ioctl(filp, cmd, arg); + ... + -> dm_blk_ioctl() @ drivers/md/dm.c + -> multipath_ioctl() @ drivers/md/dm-mpath.c + ... + (bdev = NULL, due to no active paths) + ... + if (!bdev || <...>) { + int err = scsi_verify_blk_ioctl(NULL, cmd); + if (err) + r = err; + } + ... + -> scsi_verify_blk_ioctl() @ block/scsi_ioctl.c + ... + if (bd && bd == bd->bd_contains) // not taken (bd = NULL) + return 0; + ... + if (capable(CAP_SYS_RAWIO)) // not taken (unprivileged user) + return 0; + ... + printk_ratelimited(KERN_WARNING + "%s: sending ioctl %x to a partition!\n" <...>); + + return -ENOIOCTLCMD; + <- + ... + return r ? : <...> + <- + ... + if (error == -ENOIOCTLCMD) + error = -ENOTTY; + out: + return error; + ... + +Links: +[1] http://git.qemu.org/?p=qemu.git;a=commit;h=336a6915bc7089fb20fea4ba99972ad9a97c5f52 +[2] https://libvirt.org/formatdomain.html#elementsDisks (see 'disk' -> 'device') +[3] http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html (Revision 1.2, 2002-05-03) + +Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> +Signed-off-by: Mike Snitzer <snitzer@redhat.com> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/md/dm-mpath.c | 7 ++----- + 1 file changed, 2 insertions(+), 5 deletions(-) + +--- a/drivers/md/dm-mpath.c ++++ b/drivers/md/dm-mpath.c +@@ -1553,11 +1553,8 @@ static int multipath_ioctl(struct dm_tar + /* + * Only pass ioctls through if the device sizes match exactly. + */ +- if (!bdev || ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT) { +- int err = scsi_verify_blk_ioctl(NULL, cmd); +- if (err) +- r = err; +- } ++ if (!r && ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT) ++ r = scsi_verify_blk_ioctl(NULL, cmd); + + return r ? : __blkdev_driver_ioctl(bdev, mode, cmd, arg); + } diff --git a/patches/scsi-restart-list-search-after-unlock-in-scsi_remove_target.patch b/patches/scsi-restart-list-search-after-unlock-in-scsi_remove_target.patch new file mode 100644 index 0000000..78d2398 --- /dev/null +++ b/patches/scsi-restart-list-search-after-unlock-in-scsi_remove_target.patch @@ -0,0 +1,83 @@ +From 40998193560dab6c3ce8d25f4fa58a23e252ef38 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig <hch@lst.de> +Date: Mon, 19 Oct 2015 16:35:46 +0200 +Subject: scsi: restart list search after unlock in scsi_remove_target + +commit 40998193560dab6c3ce8d25f4fa58a23e252ef38 upstream. + +When dropping a lock while iterating a list we must restart the search +as other threads could have manipulated the list under us. Without this +we can get stuck in an endless loop. This bug was introduced by + +commit bc3f02a795d3b4faa99d37390174be2a75d091bd +Author: Dan Williams <djbw@fb.com> +Date: Tue Aug 28 22:12:10 2012 -0700 + + [SCSI] scsi_remove_target: fix softlockup regression on hot remove + +Which was itself trying to fix a reported soft lockup issue + +http://thread.gmane.org/gmane.linux.kernel/1348679 + +However, we believe even with this revert of the original patch, the soft +lockup problem has been fixed by + +commit f2495e228fce9f9cec84367547813cbb0d6db15a +Author: James Bottomley <JBottomley@Parallels.com> +Date: Tue Jan 21 07:01:41 2014 -0800 + + [SCSI] dual scan thread bug fix + +Thanks go to Dan Williams <dan.j.williams@intel.com> for tracking all this +prior history down. + +Reported-by: Johannes Thumshirn <jthumshirn@suse.de> +Signed-off-by: Christoph Hellwig <hch@lst.de> +Tested-by: Johannes Thumshirn <jthumshirn@suse.de> +Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> +Fixes: bc3f02a795d3b4faa99d37390174be2a75d091bd +Signed-off-by: James Bottomley <JBottomley@Odin.com> +[lizf: Backported to 3.4: adjust context] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/scsi/scsi_sysfs.c | 16 ++++------------ + 1 file changed, 4 insertions(+), 12 deletions(-) + +--- a/drivers/scsi/scsi_sysfs.c ++++ b/drivers/scsi/scsi_sysfs.c +@@ -1020,31 +1020,23 @@ static void __scsi_remove_target(struct + void scsi_remove_target(struct device *dev) + { + struct Scsi_Host *shost = dev_to_shost(dev->parent); +- struct scsi_target *starget, *last = NULL; ++ struct scsi_target *starget; + unsigned long flags; + +- /* remove targets being careful to lookup next entry before +- * deleting the last +- */ ++restart: + spin_lock_irqsave(shost->host_lock, flags); + list_for_each_entry(starget, &shost->__targets, siblings) { + if (starget->state == STARGET_DEL) + continue; + if (starget->dev.parent == dev || &starget->dev == dev) { +- /* assuming new targets arrive at the end */ + starget->reap_ref++; + spin_unlock_irqrestore(shost->host_lock, flags); +- if (last) +- scsi_target_reap(last); +- last = starget; + __scsi_remove_target(starget); +- spin_lock_irqsave(shost->host_lock, flags); ++ scsi_target_reap(starget); ++ goto restart; + } + } + spin_unlock_irqrestore(shost->host_lock, flags); +- +- if (last) +- scsi_target_reap(last); + } + EXPORT_SYMBOL(scsi_remove_target); + diff --git a/patches/scsi_sysfs-fix-queue_ramp_up_period-return-code.patch b/patches/scsi_sysfs-fix-queue_ramp_up_period-return-code.patch new file mode 100644 index 0000000..4b302bb --- /dev/null +++ b/patches/scsi_sysfs-fix-queue_ramp_up_period-return-code.patch @@ -0,0 +1,33 @@ +From 863e02d0e173bb9d8cea6861be22820b25c076cc Mon Sep 17 00:00:00 2001 +From: Peter Oberparleiter <oberpar@linux.vnet.ibm.com> +Date: Tue, 27 Oct 2015 10:49:54 +0100 +Subject: scsi_sysfs: Fix queue_ramp_up_period return code + +commit 863e02d0e173bb9d8cea6861be22820b25c076cc upstream. + +Writing a number to /sys/bus/scsi/devices/<sdev>/queue_ramp_up_period +returns the value of that number instead of the number of bytes written. +This behavior can confuse programs expecting POSIX write() semantics. +Fix this by returning the number of bytes written instead. + +Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com> +Reviewed-by: Hannes Reinecke <hare@suse.de> +Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> +Reviewed-by: Ewan D. Milne <emilne@redhat.com> +Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/scsi/scsi_sysfs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/scsi_sysfs.c ++++ b/drivers/scsi/scsi_sysfs.c +@@ -793,7 +793,7 @@ sdev_store_queue_ramp_up_period(struct d + return -EINVAL; + + sdev->queue_ramp_up_period = msecs_to_jiffies(period); +- return period; ++ return count; + } + + static struct device_attribute sdev_attr_queue_ramp_up_period = diff --git a/patches/series b/patches/series index e69de29..b25976b 100644 --- a/patches/series +++ b/patches/series @@ -0,0 +1,32 @@ +mac80211-fix-driver-rssi-event-calculations.patch +wm831x_power-use-irqf_oneshot-to-request-threaded-irqs.patch +mwifiex-fix-mwifiex_rdeeprom_read.patch +devres-fix-a-for-loop-bounds-check.patch +arm-pxa-remove-incorrect-__init-annotation-on-pxa27x_set_pwrmode.patch +mips-atomic-fix-comment-describing-atomic64_add_unless-s-return-value.patch +recordmcount-fix-endianness-handling-bug-for-nop_mcount.patch +ipv6-fix-tunnel-error-handling.patch +scsi-restart-list-search-after-unlock-in-scsi_remove_target.patch +net-fix-a-race-in-dst_release.patch +fs-cache-increase-reference-of-parent-after-registering-netfs-success.patch +fs-cache-don-t-override-netfs-s-primary_index-if-registering-failed.patch +fs-cache-handle-a-write-to-the-page-immediately-beyond-the-eof-marker.patch +hid-core-avoid-uninitialized-buffer-access.patch +mtd-mtdpart-fix-add_mtd_partitions-error-path.patch +iommu-vt-d-fix-atsr-handling-for-root-complex-integrated-endpoints.patch +ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch +bluetooth-ath3k-add-support-of-ar3012-0cf3-817b-device.patch +staging-rtl8712-add-device-id-for-sitecom-wla2100.patch +acpi-use-correct-irq-when-uninstalling-acpi-interrupt-handler.patch +alsa-hda-disable-64bit-address-for-creative-hda-controllers.patch +megaraid_sas-do-not-use-page_size-for-max_sectors.patch +revert-dm-mpath-fix-stalls-when-handling-invalid-ioctls.patch +crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch +megaraid_sas-smap-restriction-do-not-access-user-memory-from-ioctl-code.patch +alsa-hda-apply-pin-fixup-for-hp-probook-6550b.patch +firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch +x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch +btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch +perf-fix-inherited-events-vs.-tracepoint-filters.patch +scsi_sysfs-fix-queue_ramp_up_period-return-code.patch +binfmt_elf-don-t-clobber-passed-executable-s-file-header.patch diff --git a/patches/staging-rtl8712-add-device-id-for-sitecom-wla2100.patch b/patches/staging-rtl8712-add-device-id-for-sitecom-wla2100.patch new file mode 100644 index 0000000..bdabc58 --- /dev/null +++ b/patches/staging-rtl8712-add-device-id-for-sitecom-wla2100.patch @@ -0,0 +1,29 @@ +From 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 Mon Sep 17 00:00:00 2001 +From: Larry Finger <Larry.Finger@lwfinger.net> +Date: Sun, 18 Oct 2015 22:14:48 -0500 +Subject: staging: rtl8712: Add device ID for Sitecom WLA2100 + +commit 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 upstream. + +This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file +was checked to verify that the addition is correct. + +Reported-by: Frans van de Wiel <fvdw@fvdw.eu> +Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> +Cc: Frans van de Wiel <fvdw@fvdw.eu> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/staging/rtl8712/usb_intf.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/staging/rtl8712/usb_intf.c ++++ b/drivers/staging/rtl8712/usb_intf.c +@@ -147,6 +147,7 @@ static struct usb_device_id rtl871x_usb_ + {USB_DEVICE(0x0DF6, 0x0058)}, + {USB_DEVICE(0x0DF6, 0x0049)}, + {USB_DEVICE(0x0DF6, 0x004C)}, ++ {USB_DEVICE(0x0DF6, 0x006C)}, + {USB_DEVICE(0x0DF6, 0x0064)}, + /* Skyworth */ + {USB_DEVICE(0x14b2, 0x3300)}, diff --git a/patches/wm831x_power-use-irqf_oneshot-to-request-threaded-irqs.patch b/patches/wm831x_power-use-irqf_oneshot-to-request-threaded-irqs.patch new file mode 100644 index 0000000..09d8c2d --- /dev/null +++ b/patches/wm831x_power-use-irqf_oneshot-to-request-threaded-irqs.patch @@ -0,0 +1,50 @@ +From 90adf98d9530054b8e665ba5a928de4307231d84 Mon Sep 17 00:00:00 2001 +From: Valentin Rothberg <valentinrothberg@gmail.com> +Date: Tue, 22 Sep 2015 19:00:40 +0200 +Subject: wm831x_power: Use IRQF_ONESHOT to request threaded IRQs + +commit 90adf98d9530054b8e665ba5a928de4307231d84 upstream. + +Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests") +threaded IRQs without a primary handler need to be requested with +IRQF_ONESHOT, otherwise the request will fail. + +scripts/coccinelle/misc/irqf_oneshot.cocci detected this issue. + +Fixes: b5874f33bbaf ("wm831x_power: Use genirq") +Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com> +Signed-off-by: Sebastian Reichel <sre@kernel.org> +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + drivers/power/wm831x_power.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/power/wm831x_power.c ++++ b/drivers/power/wm831x_power.c +@@ -567,7 +567,7 @@ static __devinit int wm831x_power_probe( + + irq = platform_get_irq_byname(pdev, "SYSLO"); + ret = request_threaded_irq(irq, NULL, wm831x_syslo_irq, +- IRQF_TRIGGER_RISING, "System power low", ++ IRQF_TRIGGER_RISING | IRQF_ONESHOT, "System power low", + power); + if (ret != 0) { + dev_err(&pdev->dev, "Failed to request SYSLO IRQ %d: %d\n", +@@ -577,7 +577,7 @@ static __devinit int wm831x_power_probe( + + irq = platform_get_irq_byname(pdev, "PWR SRC"); + ret = request_threaded_irq(irq, NULL, wm831x_pwr_src_irq, +- IRQF_TRIGGER_RISING, "Power source", ++ IRQF_TRIGGER_RISING | IRQF_ONESHOT, "Power source", + power); + if (ret != 0) { + dev_err(&pdev->dev, "Failed to request PWR SRC IRQ %d: %d\n", +@@ -588,7 +588,7 @@ static __devinit int wm831x_power_probe( + for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) { + irq = platform_get_irq_byname(pdev, wm831x_bat_irqs[i]); + ret = request_threaded_irq(irq, NULL, wm831x_bat_irq, +- IRQF_TRIGGER_RISING, ++ IRQF_TRIGGER_RISING | IRQF_ONESHOT, + wm831x_bat_irqs[i], + power); + if (ret != 0) { diff --git a/patches/x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch b/patches/x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch new file mode 100644 index 0000000..dce8226 --- /dev/null +++ b/patches/x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch @@ -0,0 +1,116 @@ +From 04633df0c43d710e5f696b06539c100898678235 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov <bp@suse.de> +Date: Thu, 5 Nov 2015 16:57:56 +0100 +Subject: x86/cpu: Call verify_cpu() after having entered long mode too + +commit 04633df0c43d710e5f696b06539c100898678235 upstream. + +When we get loaded by a 64-bit bootloader, kernel entry point is +startup_64 in head_64.S. We don't trust any and all bootloaders because +some will fiddle with CPU configuration so we go ahead and massage each +CPU into sanity again. + +For example, some dell BIOSes have this XD disable feature which set +IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround +for other OSes but Linux sure doesn't need it. + +A similar thing is present in the Surface 3 firmware - see +https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit +only on the BSP: + + # rdmsr -a 0x1a0 + 400850089 + 850089 + 850089 + 850089 + +I know, right?! + +There's not even an off switch in there. + +So fix all those cases by sanitizing the 64-bit entry point too. For +that, make verify_cpu() callable in 64-bit mode also. + +Requested-and-debugged-by: "H. Peter Anvin" <hpa@zytor.com> +Reported-and-tested-by: Bastien Nocera <bugzilla@hadess.net> +Signed-off-by: Borislav Petkov <bp@suse.de> +Cc: Matt Fleming <matt@codeblueprint.co.uk> +Cc: Peter Zijlstra <peterz@infradead.org> +Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.de +Signed-off-by: Thomas Gleixner <tglx@linutronix.de> +[lizf: Backported to 3.4: adjust context] +Signed-off-by: Zefan Li <lizefan@huawei.com> +--- + arch/x86/kernel/head_64.S | 8 ++++++++ + arch/x86/kernel/verify_cpu.S | 12 +++++++----- + 2 files changed, 15 insertions(+), 5 deletions(-) + +--- a/arch/x86/kernel/head_64.S ++++ b/arch/x86/kernel/head_64.S +@@ -45,6 +45,9 @@ L3_START_KERNEL = pud_index(__START_KERN + .globl startup_64 + startup_64: + ++ /* Sanitize CPU configuration */ ++ call verify_cpu ++ + /* + * At this point the CPU runs in 64bit mode CS.L = 1 CS.D = 1, + * and someone has loaded an identity mapped page table +@@ -160,6 +163,9 @@ ENTRY(secondary_startup_64) + * after the boot processor executes this code. + */ + ++ /* Sanitize CPU configuration */ ++ call verify_cpu ++ + /* Enable PAE mode and PGE */ + movl $(X86_CR4_PAE | X86_CR4_PGE), %eax + movq %rax, %cr4 +@@ -253,6 +259,8 @@ ENTRY(secondary_startup_64) + pushq %rax # target address in negative space + lretq + ++#include "verify_cpu.S" ++ + /* SMP bootup changes these two */ + __REFDATA + .align 8 +--- a/arch/x86/kernel/verify_cpu.S ++++ b/arch/x86/kernel/verify_cpu.S +@@ -34,10 +34,11 @@ + #include <asm/msr-index.h> + + verify_cpu: +- pushfl # Save caller passed flags +- pushl $0 # Kill any dangerous flags +- popfl ++ pushf # Save caller passed flags ++ push $0 # Kill any dangerous flags ++ popf + ++#ifndef __x86_64__ + pushfl # standard way to check for cpuid + popl %eax + movl %eax,%ebx +@@ -48,6 +49,7 @@ verify_cpu: + popl %eax + cmpl %eax,%ebx + jz verify_cpu_no_longmode # cpu has no cpuid ++#endif + + movl $0x0,%eax # See if cpuid 1 is implemented + cpuid +@@ -130,10 +132,10 @@ verify_cpu_sse_test: + jmp verify_cpu_sse_test # try again + + verify_cpu_no_longmode: +- popfl # Restore caller passed flags ++ popf # Restore caller passed flags + movl $1,%eax + ret + verify_cpu_sse_ok: +- popfl # Restore caller passed flags ++ popf # Restore caller passed flags + xorl %eax, %eax + ret |