- 01 Jan, 2015 1 commit
-
-
Daniel Vetter authored
commit b0616c53 upstream. Otherwise we'll have backtraces in assert_panel_unlocked because the BIOS locks the register. In the reporter's case this regression was introduced in commit c31407a3 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 18 21:07:01 2012 +0100 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H Reported-by:
Alexey Orishko <alexey.orishko@gmail.com> Cc: Alexey Orishko <alexey.orishko@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Francois Tigeot <ftigeot@wolfpond.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Tested-by:
Jani Nikula <jani.nikula@intel.com> [bwh: Backported to 3.2: adjust context; comment was duplicated] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
- 14 Dec, 2014 39 commits
-
-
Ben Hutchings authored
-
Jan Kara authored
commit f55fefd1 upstream. The WARN_ON checking whether i_mutex is held in pagecache_isize_extended() was wrong because some filesystems (e.g. XFS) use different locks for serialization of truncates / writes. So just remove the check. Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
Pawel Moll authored
commit b3f20785 upstream. When running a 32-bit userspace on a 64-bit kernel (eg. i386 application on x86_64 kernel or 32-bit arm userspace on arm64 kernel) some of the perf ioctls must be treated with special care, as they have a pointer size encoded in the command. For example, PERF_EVENT_IOC_ID in 32-bit world will be encoded as 0x80042407, but 64-bit kernel will expect 0x80082407. In result the ioctl will fail returning -ENOTTY. This patch solves the problem by adding code fixing up the size as compat_ioctl file operation. Reported-by:
Drew Richardson <drew.richardson@arm.com> Signed-off-by:
Pawel Moll <pawel.moll@arm.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/1402671812-9078-1-git-send-email-pawel.moll@arm.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: David Ahern <dsahern@gmail.com> [lizf: Backported to 3.4 by David Ahern] Signed-off-by:
Zefan Li <lizefan@huawei.com> Signed-off-by:
-
Ondrej Kozina authored
commit e2cffb5f upstream. On archs with PAGE_SIZE >= 64 KiB the function skcipher_alloc_sgl() fails with -ENOMEM no matter what user space actually requested. This is caused by the fact sock_kmalloc call inside the function tried to allocate more memory than allowed by the default kernel socket buffer size (kernel param net.core.optmem_max). Signed-off-by:
Ondrej Kozina <okozina@redhat.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jeffrey Knockel authored
With commits 73f156a6 ("inetpeer: get rid of ip_id_count") and 04ca6973 ("ip: make IP identifiers less predictable"), IP identifiers are generated from a counter chosen from an array of counters indexed by the hash of the outgoing packet header's source address, destination address, and protocol number. Thus, in __ip_make_skb(), we must now call ip_select_ident() only after setting these fields in the IP header to prevent IP identifiers from being generated from bogus counters. IP id sequence before fix: 18174, 5789, 5953, 59420, 59637, ... After fix: 5967, 6185, 6374, 6600, 6795, 6892, 7051, 7288, ... Signed-off-by:
Jeffrey Knockel <jeffk@cs.unm.edu> Signed-off-by:
-
Tomas Henzl authored
commit 2cc5bfaf upstream. When the driver calls scsi_done and after that frees it's internal preallocated memory it can happen that a new job is enqueud before the memory is freed. The allocation fails and the message "cmd_alloc returned NULL" is shown. Patch below fixes it by moving cmd->scsi_done after cmd_free. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Acked-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Eric Dumazet authored
commit bd14b1b2 upstream. It appears some networks play bad games with the two bits reserved for ECN. This can trigger false congestion notifications and very slow transferts. Since RFC 3168 (6.1.1) forbids SYN packets to carry CT bits, we can disable TCP ECN negociation if it happens we receive mangled CT bits in the SYN packet. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Perry Lorier <perryl@google.com> Cc: Matt Mathis <mattmathis@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Wilmer van der Gaast <wilmer@google.com> Cc: Ankur Jain <jankur@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Dave Täht <dave.taht@bufferbloat.net> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Tomas Winkler authored
commit 6adb8efb upstream. give up reseting after 3 unsuccessful tries [Backported to 3.2: files were moved] Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Tomas Winkler authored
commit 9a123f19 upstream. The main purpose of this function is to exclude ME devices without support for MEI/HECI interface from binding Currently affected systems are C600/X79 based servers that expose PCI device even though it doesn't supported ME Interface. MEI driver accessing such nonfunctional device can corrupt the system. [Backported to 3.2: files were moved] Signed-off-by:
-
Greg Kroah-Hartman authored
commit a1f9a407 upstream. The xpad wireless endpoint is not a bulk endpoint on my devices, but rather an interrupt one, so the USB core complains when it is submitted. I'm guessing that the author really did mean that this should be an interrupt urb, but as there are a zillion different xpad devices out there, let's cover out bases and handle both bulk and interrupt endpoints just as easily. Signed-off-by:
"Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Hans de Goede authored
commit 263e80b4 upstream. This wireless mouse receiver needs a reset-resume quirk to properly come out of reset. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Aaro Koskinen authored
commit 26927f76 upstream. If SERIAL_8250 is compiled as a module, the platform specific setup for Loongson will be a module too, and it will not work very well. At least on Loongson 3 it will trigger a build failure, since loongson_sysconf is not exported to modules. Fix by making the platform specific serial code always built-in. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Reported-by:
Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: Huacai Chen <chenhc@lemote.com> Cc: Markos Chandras <Markos.Chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/8533/Signed-off-by:
-
Takashi Iwai authored
commit 413cbf46 upstream. AMD/ATI HDMI controller chip models, we already have a filter to lower to 32bit DMA, but the rest are supposed to be working with 64bit although the hardware doesn't really work with 63bit but only with 40 or 48bit DMA. In this patch, we take 40bit DMA for safety for the AMD/ATI controllers as the graphics drivers does. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> [bwh: Backported to 3.2: - Adjust context - s/AZX_GCAP_64OK/ICH6_GCAP_64OK/] Signed-off-by:
-
Andy Lutomirski authored
commit 7ddc6a21 upstream. These functions can be executed on the int3 stack, so kprobes are dangerous. Tracing is probably a bad idea, too. Fixes: b645af2d ("x86_64, traps: Rework bad_iret") Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/50e33d26adca60816f3ba968875801652507d0c4.1416870125.git.luto@amacapital.netSigned-off-by:
-
Andy Lutomirski authored
commit b645af2d upstream. It's possible for iretq to userspace to fail. This can happen because of a bad CS, SS, or RIP. Historically, we've handled it by fixing up an exception from iretq to land at bad_iret, which pretends that the failed iret frame was really the hardware part of #GP(0) from userspace. To make this work, there's an extra fixup to fudge the gs base into a usable state. This is suboptimal because it loses the original exception. It's also buggy because there's no guarantee that we were on the kernel stack to begin with. For example, if the failing iret happened on return from an NMI, then we'll end up executing general_protection on the NMI stack. This is bad for several reasons, the most immediate of which is that general_protection, as a non-paranoid idtentry, will try to deliver signals and/or schedule from the wrong stack. This patch throws out bad_iret entirely. As a replacement, it augments the existing swapgs fudge into a full-blown iret fixup, mostly written in C. It's should be clearer and more correct. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 3.2: - We didn't use the _ASM_EXTABLE macro - Don't use __visible] Signed-off-by:
-
Andy Lutomirski authored
commit af726f21 upstream. There's nothing special enough about the espfix64 double fault fixup to justify writing it in assembly. Move it to C. This also fixes a bug: if the double fault came from an IST stack, the old asm code would return to a partially uninitialized stack frame. Fixes: 3891a04aSigned-off-by:
-
Andy Lutomirski authored
commit 6f442be2 upstream. On a 32-bit kernel, this has no effect, since there are no IST stacks. On a 64-bit kernel, #SS can only happen in user code, on a failed iret to user space, a canonical violation on access via RSP or RBP, or a genuine stack segment violation in 32-bit kernel code. The first two cases don't need IST, and the latter two cases are unlikely fatal bugs, and promoting them to double faults would be fine. This fixes a bug in which the espfix64 code mishandles a stack segment violation. This saves 4k of memory per CPU and a tiny bit of code. Signed-off-by:
-
Lu Baolu authored
commit a1377e53 upstream. When system is being suspended, if host device is not allowed to do wakeup, xhci_suspend() needs to clear all root port wake on bits. Otherwise, some platforms may generate spurious wakeup, even if PCI PME# is disabled. The initial commit ff8cbf25 ("xhci: clear root port wake on bits"), which also got into stable, turned out to not work correctly and had to be reverted, and is now rewritten. Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Suggested-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 8e71a322 upstream. If a device is halted and reuturns a STALL, then the halted endpoint needs to be cleared both on the host and device side. The host side halt is cleared by issueing a xhci reset endpoint command. The device side is cleared with a ClearFeature(ENDPOINT_HALT) request, which should be issued by the device driver if a URB reruen -EPIPE. Previously we cleared the host side halt after the device side was cleared. To make sure the host side halt is cleared in time we want to issue the reset endpoint command immedialtely when a STALL status is encountered. Otherwise we end up not following the specs and not returning -EPIPE several times in a row when trying to transfer data to a halted endpoint. Fixes: bcef3fd5 (USB: xhci: Handle errors that cause endpoint halts.) Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Lu Baolu authored
commit 9b41ebd3 upstream. commit ff8cbf25 ("xhci: clear root port wake on bits if controller isn't") can cause device detection error if runtime PM is enabled, and S3 wake is disabled. Revert it. https://bugzilla.kernel.org/show_bug.cgi?id=85701 This commit got into stable and should be reverted from there as well. Signed-off-by:
Dmitry Nezhevenko <dion@inhex.net> [Mathias Nyman: reword commit message] Signed-off-by:
-
Mathias Nyman authored
commit c3492dbf upstream. A halted endpoint ring must first be reset, then move the ring dequeue pointer past the problematic TRB. If we start the ring too early after reset, but before moving the dequeue pointer we will end up executing the same problematic TRB again. As we always issue a set transfer dequeue command after a reset endpoint command we can skip starting endpoint rings at reset endpoint command completion. Without this fix we end up trying to handle the same faulty TD for contol endpoints. causing timeout, and failing testusb ctrl_out write tests. Fixes: e9df17eb (USB: xhci: Correct assumptions about number of rings per endpoint.) Tested-by:
-
Dmitry Eremin-Solenikov authored
commit ef59a20b upstream. According to the manuals I have, XScale auxiliary register should be reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to also use c1, c0, 1. The issue was primarily noticed thanks to qemu reporing "unsupported instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255 XScale Core manuals and in PXA270 and PXA320 Developers Guides. Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board. Tested-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Maurizio Lombardi authored
commit 01a4cc4d upstream. In some cases, the fcoe_rx_list may contains multiple instances of the same skb (the so called "shared skbs"). the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list, modifies (and destroys) its content and then proceed to the next one. The problem is that if the skb is shared, the remaining instances will be corrupted. The solution is to use skb_share_check() before adding the skb to the fcoe_rx_list. [ 6286.808725] ------------[ cut here ]------------ [ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]() [ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio] [ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1 [ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 6286.808752] 0000000000000000 000000000b36e715 ffff8800deba1e00 ffffffff815ec0ba [ 6286.808753] ffff8800deba1e38 ffffffff8105dee1 ffffffffa05618c0 ffff8801e4c81888 [ 6286.808754] ffffe8ffff663868 ffff8801f402b180 ffff8801f56bc000 ffff8800deba1e48 [ 6286.808754] Call Trace: [ 6286.808759] [<ffffffff815ec0ba>] dump_stack+0x19/0x1b [ 6286.808762] [<ffffffff8105dee1>] warn_slowpath_common+0x61/0x80 [ 6286.808763] [<ffffffff8105e00a>] warn_slowpath_null+0x1a/0x20 [ 6286.808765] [<ffffffffa054f415>] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc] [ 6286.808767] [<ffffffffa054eff0>] ? bnx2fc_disable+0x90/0x90 [bnx2fc] [ 6286.808769] [<ffffffff81085aef>] kthread+0xcf/0xe0 [ 6286.808770] [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140 [ 6286.808772] [<ffffffff815fc76c>] ret_from_fork+0x7c/0xb0 [ 6286.808773] [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140 [ 6286.808774] ---[ end trace c6cdb939184ccb4e ]--- Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Acked-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Trond Myklebust authored
commit c6c15e1e upstream. The currect code for nfsd41_cb_get_slot() and nfsd4_cb_done() has no locking in order to guarantee atomicity, and so allows for races of the form. Task 1 Task 2 ====== ====== if (test_and_set_bit(0) != 0) { clear_bit(0) rpc_wake_up_next(queue) rpc_sleep_on(queue) return false; } This patch breaks the race condition by adding a retest of the bit after the call to rpc_sleep_on(). Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Aaro Koskinen authored
commit bbaf113a upstream. Fix incorrect cast that always results in wrong address for the new frame on 64-bit kernels. Signed-off-by:
Aaro Koskinen <aaro.koskinen@nsn.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8110/Signed-off-by:
-
Trond Myklebust authored
commit 093a1468 upstream. Both xprt_lookup_rqst() and xprt_complete_rqst() require that you take the transport lock in order to avoid races with xprt_transmit(). Signed-off-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
-
Chuck Lever authored
commit 71efecb3 upstream. xprt_lookup_rqst() and bc_send_request() display a byte-swapped XID, but receive_cb_reply() does not. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Johan Hovold authored
commit 75bcbf29 upstream. Fix reporting of overrun errors, which should only be reported once using the inserted null character. Fixes: 6b8f1ca5 ("USB: ssu100: set tty_flags in ssu100_process_packet") Signed-off-by:
Johan Hovold <johan@kernel.org> [bwh: Backported to 3.2: - Use tty_port_tty_get() to look up tty_struct - Adjust context] Signed-off-by:
-
Johan Hovold authored
commit 855515a6 upstream. Fix reporting of overrun errors, which are not associated with a character. Instead insert a null character and report only once. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Johan Hovold authored
commit 5d1678a3 upstream. Fix handling of TTY error flags, which are not bitmasks and must specifically not be ORed together as this prevents the line discipline from recognising them. Also insert null characters when reporting overrun errors as these are not associated with the received character. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Troy Clark authored
commit 204ec6e0 upstream. Add PIDs for new Matrix Orbital GTT series products. Signed-off-by:
Troy Clark <tclark@matrixorbital.ca> [johan: shorten commit message ] Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 746c9e9f upstream. We have a historical hack that treats missing ranges properties as the equivalent of an empty one. This is needed for ancient PowerMac "bad" device-trees, and shouldn't be enabled for any other PowerPC platform, otherwise we get some nasty layout of devices in sysfs or even duplication when a set of otherwise identically named devices is created multiple times under a different parent node with no ranges property. This fix is needed for the PowerNV i2c busses to be exposed properly and will fix a number of other embedded cases. Signed-off-by:
Grant Likely <grant.likely@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> [bwh: Backported to 3.2: use #ifdef because IS_ENABLED() only works for config symbols that are defined on the current architecture] Signed-off-by:
-
Kees Cook authored
commit 45e2a9d4 upstream. When setting up permissions on kernel memory at boot, the end of the PMD that was split from bss remained executable. It should be NX like the rest. This performs a PMD alignment instead of a PAGE alignment to get the correct span of memory. Before: ---[ High Kernel Mapping ]--- ... 0xffffffff8202d000-0xffffffff82200000 1868K RW GLB NX pte 0xffffffff82200000-0xffffffff82c00000 10M RW PSE GLB NX pmd 0xffffffff82c00000-0xffffffff82df5000 2004K RW GLB NX pte 0xffffffff82df5000-0xffffffff82e00000 44K RW GLB x pte 0xffffffff82e00000-0xffffffffc0000000 978M pmd After: ---[ High Kernel Mapping ]--- ... 0xffffffff8202d000-0xffffffff82200000 1868K RW GLB NX pte 0xffffffff82200000-0xffffffff82e00000 12M RW PSE GLB NX pmd 0xffffffff82e00000-0xffffffffc0000000 978M pmd [ tglx: Changed it to roundup(_brk_end, PMD_SIZE) and added a comment. We really should unmap the reminder along with the holes caused by init,initdata etc. but thats a different issue ] Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Toshi Kani <toshi.kani@hp.com> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Wang Nan <wangnan0@huawei.com> Cc: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/20141114194737.GA3091@www.outflux.netSigned-off-by:
-
Yinghai Lu authored
commit 72212675 upstream. HPA said, we should not have RW and +x set at the time. for kernel layout: [ 0.000000] Kernel Layout: [ 0.000000] .text: [0x01000000-0x021434f8] [ 0.000000] .rodata: [0x02200000-0x02a13fff] [ 0.000000] .data: [0x02c00000-0x02dc763f] [ 0.000000] .init: [0x02dc9000-0x0312cfff] [ 0.000000] .bss: [0x0313b000-0x03dd6fff] [ 0.000000] .brk: [0x03dd7000-0x03dfffff] before the patch, we have ---[ High Kernel Mapping ]--- 0xffffffff80000000-0xffffffff81000000 16M pmd 0xffffffff81000000-0xffffffff82200000 18M ro PSE GLB x pmd 0xffffffff82200000-0xffffffff82c00000 10M ro PSE GLB NX pmd 0xffffffff82c00000-0xffffffff82dc9000 1828K RW GLB x pte 0xffffffff82dc9000-0xffffffff82e00000 220K RW GLB NX pte 0xffffffff82e00000-0xffffffff83000000 2M RW PSE GLB NX pmd 0xffffffff83000000-0xffffffff8313a000 1256K RW GLB NX pte 0xffffffff8313a000-0xffffffff83200000 792K RW GLB x pte 0xffffffff83200000-0xffffffff83e00000 12M RW PSE GLB x pmd 0xffffffff83e00000-0xffffffffa0000000 450M pmd after patch,, we get ---[ High Kernel Mapping ]--- 0xffffffff80000000-0xffffffff81000000 16M pmd 0xffffffff81000000-0xffffffff82200000 18M ro PSE GLB x pmd 0xffffffff82200000-0xffffffff82c00000 10M ro PSE GLB NX pmd 0xffffffff82c00000-0xffffffff82e00000 2M RW GLB NX pte 0xffffffff82e00000-0xffffffff83000000 2M RW PSE GLB NX pmd 0xffffffff83000000-0xffffffff83200000 2M RW GLB NX pte 0xffffffff83200000-0xffffffff83e00000 12M RW PSE GLB NX pmd 0xffffffff83e00000-0xffffffffa0000000 450M pmd so data, bss, brk get NX ... Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/1359058816-7615-33-git-send-email-yinghai@kernel.orgSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Alexey Khoroshilov authored
commit efbd50d2 upstream. It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds the missing deallocation. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by:
Matthias Fuchs <matthias.fuchs@esd.eu> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Thomas Körper authored
commit 5247a589 upstream. ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX Error) interrupt, which triggers the folloing warning: [ 1153.360705] ------------[ cut here ]------------ [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0() [ 1153.360772] Call Trace: [ 1153.360778] [<c167906f>] dump_stack+0x41/0x52 [ 1153.360782] [<c105bb7e>] warn_slowpath_common+0x7e/0xa0 [ 1153.360784] [<c158b909>] ? skb_release_head_state+0xb9/0xd0 [ 1153.360786] [<c158b909>] ? skb_release_head_state+0xb9/0xd0 [ 1153.360788] [<c105bc42>] warn_slowpath_null+0x22/0x30 [ 1153.360791] [<c158b909>] skb_release_head_state+0xb9/0xd0 [ 1153.360793] [<c158be90>] skb_release_all+0x10/0x30 [ 1153.360795] [<c158bf06>] kfree_skb+0x36/0x80 [ 1153.360799] [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev] [ 1153.360802] [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev] [ 1153.360805] [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402] [ 1153.360809] [<c10a75b5>] handle_irq_event_percpu+0x35/0x180 [ 1153.360811] [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180 [ 1153.360813] [<c10a7731>] handle_irq_event+0x31/0x50 [ 1153.360816] [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120 [ 1153.360818] [<c10a9c10>] ? handle_edge_irq+0x110/0x110 [ 1153.360822] [<c1011b61>] handle_irq+0x71/0x90 [ 1153.360823] <IRQ> [<c168152c>] do_IRQ+0x3c/0xd0 [ 1153.360829] [<c1680b6c>] common_interrupt+0x2c/0x34 [ 1153.360834] [<c107d277>] ? finish_task_switch+0x47/0xf0 [ 1153.360836] [<c167c27b>] __schedule+0x35b/0x7e0 [ 1153.360839] [<c10a5334>] ? console_unlock+0x2c4/0x4d0 [ 1153.360842] [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890 [ 1153.360845] [<c10707b6>] ? process_one_work+0x196/0x370 [ 1153.360847] [<c167c723>] schedule+0x23/0x60 [ 1153.360849] [<c1070de1>] worker_thread+0x161/0x460 [ 1153.360852] [<c1090fcf>] ? __wake_up_locked+0x1f/0x30 [ 1153.360854] [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0 [ 1153.360856] [<c1074f01>] kthread+0xa1/0xc0 [ 1153.360859] [<c1680401>] ret_from_kernel_thread+0x21/0x30 [ 1153.360861] [<c1074e60>] ? kthread_create_on_node+0x110/0x110 [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]--- This patch replaces the kfree_skb() by dev_kfree_skb_any(). Signed-off-by:
Thomas Körper <thomas.koerper@esd.eu> Signed-off-by:
-
Dave Hansen authored
commit 2cd3949f upstream. We have some very similarly named command-line options: arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup); arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup); arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup); __setup() is designed to match options that take arguments, like "foo=bar" where you would have: __setup("foo", x86_foo_func...); The problem is that "noxsave" actually _matches_ "noxsaves" in the same way that "foo" matches "foo=bar". If you boot an old kernel that does not know about "noxsaves" with "noxsaves" on the command line, it will interpret the argument as "noxsave", which is not what you want at all. This makes the "noxsave" handler only return success when it finds an *exact* match. [ tglx: We really need to make __setup() more robust. ] Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Hansen <dave@sr71.net> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: x86@kernel.org Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.comSigned-off-by:
-
Cristina Ciocan authored
commit ccf54555 upstream. The direction field is set on 7 bits, thus we need to AND it with 0111 111 mask in order to retrieve it, that is 0x7F, not 0xCF as it is now. Fixes: ade7ef7b (staging:iio: Differential channel handling) Signed-off-by:
Cristina Ciocan <cristina.ciocan@intel.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> [bwh: Backported to 3.2: adjust filename] Signed-off-by:
-
Stefan Richter authored
commit eaca2d8e upstream. Found by the UC-KLEE tool: A user could supply less input to firewire-cdev ioctls than write- or write/read-type ioctl handlers expect. The handlers used data from uninitialized kernel stack then. This could partially leak back to the user if the kernel subsequently generated fw_cdev_event_'s (to be read from the firewire-cdev fd) which notably would contain the _u64 closure field which many of the ioctl argument structures contain. The fact that the handlers would act on random garbage input is a lesser issue since all handlers must check their input anyway. The fix simply always null-initializes the entire ioctl argument buffer regardless of the actual length of expected user input. That is, a runtime overhead of memset(..., 40) is added to each firewirew-cdev ioctl() call. [Comment from Clemens Ladisch: This part of the stack is most likely to be already in the cache.] Remarks: - There was never any leak from kernel stack to the ioctl output buffer itself. IOW, it was not possible to read kernel stack by a read-type or write/read-type ioctl alone; the leak could at most happen in combination with read()ing subsequent event data. - The actual expected minimum user input of each ioctl from include/uapi/linux/firewire-cdev.h is, in bytes: [0x00] = 32, [0x05] = 4, [0x0a] = 16, [0x0f] = 20, [0x14] = 16, [0x01] = 36, [0x06] = 20, [0x0b] = 4, [0x10] = 20, [0x15] = 20, [0x02] = 20, [0x07] = 4, [0x0c] = 0, [0x11] = 0, [0x16] = 8, [0x03] = 4, [0x08] = 24, [0x0d] = 20, [0x12] = 36, [0x17] = 12, [0x04] = 20, [0x09] = 24, [0x0e] = 4, [0x13] = 40, [0x18] = 4. Reported-by:
David Ramos <daramos@stanford.edu> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
