- 21 May, 2012 3 commits
-
-
David Vrabel authored
commit 76a8df7b upstream. The accessing PCI configuration space with the PCI BIOS32 service does not work in PV guests. On systems without MMCONFIG or where the BIOS hasn't marked the MMCONFIG region as reserved in the e820 map, the BIOS service is probed (even though direct access is preferred) and this hangs. Acked-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> [v1: Fixed compile error when CONFIG_PCI is not set] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Konrad Rzeszutek Wilk authored
commit b7e5ffe5 upstream. If I try to do "cat /sys/kernel/debug/kernel_page_tables" I end up with: BUG: unable to handle kernel paging request at ffffc7fffffff000 IP: [<ffffffff8106aa51>] ptdump_show+0x221/0x480 PGD 0 Oops: 0000 [#1] SMP CPU 0 .. snip.. RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000 RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000 which is due to the fact we are trying to access a PFN that is not accessible to us. The reason (at least in this case) was that PGD[256] is set to __HYPERVISOR_VIRT_START which was setup (by the hypervisor) to point to a read-only linear map of the MFN->PFN array. During our parsing we would get the MFN (a valid one), try to look it up in the MFN->PFN tree and find it invalid and return ~0 as PFN. Then pte_mfn_to_pfn would happilly feed that in, attach the flags and return it back to the caller. 'ptdump_show' bitshifts it and gets and invalid value that it tries to dereference. Instead of doing all of that, we detect the ~0 case and just return !_PAGE_PRESENT. This bug has been in existence .. at least until 2.6.37 (yikes!) Signed-off-by:
-
Paolo Pisati authored
commit 07d69d42 upstream. Without this patch sysfs reports the cable as present flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier 1 while it's not: flag@flag-desktop:~$ sudo mii-tool eth0 eth0: no link Tested on my Beagle XM. v2: added mantainer to the list of recipient Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
- 07 May, 2012 37 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
commit 6f24f892 upstream. Commit ec81aecb ("hfs: fix a potential buffer overflow") fixed a few potential buffer overflows in the hfs filesystem. But as Timo Warns pointed out, these changes also need to be made on the hfsplus filesystem as well. Reported-by:
Timo Warns <warns@pre-sense.de> Acked-by:
WANG Cong <amwang@redhat.com> Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Sage Weil <sage@newdream.net> Cc: Eugene Teo <eteo@redhat.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Dave Anderson <anderson@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Peter Zijlstra authored
commit c308b56b upstream. [ backported to 3.0 by Kerin Millar <kerframil@gmail.com>] Various people reported nohz load tracking still being wrecked, but Doug spotted the actual problem. We fold the nohz remainder in too soon, causing us to loose samples and under-account. So instead of playing catch-up up-front, always do a single load-fold with whatever state we encounter and only then fold the nohz remainder and play catch-up. Reported-by:
Doug Smythies <dsmythies@telus.net> Reported-by:
LesÅ=82aw Kope=C4=87 <leslaw.kopec@nasza-klasa.pl> Reported-by:
Aman Gupta <aman@tmm1.net> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/n/tip-4v31etnhgg9kwd6ocgx3rxl8@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Kerin Millar <kerframil@gmail.com> Signed-off-by:
-
Grazvydas Ignotas authored
commit 4c1bcdb5 upstream. This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Grazvydas Ignotas authored
commit 328c32f0 upstream. Currently SDIO glue frees it's own structure before calling wl1251_free_hw(), which in turn calls ieee80211_unregister_hw(). The later call may result in a need to communicate with the chip to stop it (as it happens now if the interface is still up before rmmod), which means calls are made back to the glue, resulting in freed memory access. Fix this by freeing glue data last. Signed-off-by:
-
Larry Finger authored
commit 44eb65cf upstream. Under some circumstances, a PCI-based driver reports the following OOPs: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP: 0010:[<ffffffffa0418d39>] [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid: 19627, threadinfo ffff880050262000, task ffff8801156d5cc0) Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002 ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282 0000000180150014 ffff880050263fd8 ffff8801176c2810 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8 ffffffff810550e2 00000000000002c0 ffff8801176c0d40 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [<ffffffffa03348e7>] _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1 e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP <ffff880050263b58> Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0 Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace 8636c766dcfbe0e6 ]--- This oops is due to interrupts not being disabled in this particular path. Reported-by:
Dave Airlie <airlied@gmail.com> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Felix Fietkau authored
commit 66f2c99a upstream. EAP frames for stations in an AP VLAN are sent on the main AP interface to avoid race conditions wrt. moving stations. For that to work properly, sta_info_get_bss must be used instead of sta_info_get when sending EAP packets. Previously this was only done for cooked monitor injected packets, so this patch adds a check for tx->skb->protocol to the same place. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Stanislav Yakovlev authored
commit dd447319 upstream. Driver incorrectly validates command completion: instead of waiting for a command to be acknowledged it continues execution. Most of the time driver gets acknowledge of the command completion in a tasklet before it executes the next one. But sometimes it sends the next command before it gets acknowledge for the previous one. In such a case one of the following error messages appear in the log: Failed to send SYSTEM_CONFIG: Already sending a command. Failed to send ASSOCIATE: Already sending a command. Failed to send TX_POWER: Already sending a command. After that you need to reload the driver to get it working again. This bug occurs during roaming (reported by Sam Varshavchik) https://bugzilla.redhat.com/show_bug.cgi?id=738508 and machine booting (reported by Tom Gundersen and Mads Kiilerich) https://bugs.archlinux.org/task/28097 https://bugzilla.redhat.com/show_bug.cgi?id=802106 This patch doesn't fix the delay issue during firmware load. But at least device now works as usual after boot. Signed-off-by:
Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by:
-
Roland Stigge authored
commit 6c557cfe upstream. In the driver's suspend function, clk_enable() was used instead of clk_disable(). This is corrected with this patch. Signed-off-by:
Roland Stigge <stigge@antcom.de> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> [wsa: reworded commit header slightly] Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
-
Lin Ming authored
commit 6868225e upstream. Commit d9027470("[libata] Add ATA transport class") introduced ATA_EFLAG_OLD_ER to mark entries in the error ring as cleared. But ata_count_probe_trials_cb() didn't check this flag and it still counts the old error history. So wrong probe trials count is returned and it causes problem, for example, SATA link speed is slowed down from 3.0Gbps to 1.5Gbps. Fix it by checking ATA_EFLAG_OLD_ER in ata_count_probe_trials_cb(). Signed-off-by:
Lin Ming <ming.m.lin@intel.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Kirill A. Shutemov authored
commit b7048711 upstream. coretemp tries to access core_data array beyond bounds on cpu unplug if core id of the cpu if more than NUM_REAL_CORES-1. BUG: unable to handle kernel NULL pointer dereference at 000000000000013c IP: [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] PGD 673e5a067 PUD 66e9b3067 PMD 0 Oops: 0000 [#1] SMP CPU 79 Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter nf_conntrack_ipv4 nf_defrag_ipv4 ip6_tables xt_state nf_conntrack coretemp crc32c_intel asix tpm_tis pcspkr usbnet iTCO_wdt i2c_i801 microcode mii joydev tpm i2c_core iTCO_vendor_support tpm_bios i7core_edac igb ioatdma edac_core dca megaraid_sas [last unloaded: oprofile] Pid: 3315, comm: set-cpus Tainted: G W 3.4.0-rc5+ #2 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[<ffffffffa00159af>] [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] RSP: 0018:ffff880472fb3d48 EFLAGS: 00010246 RAX: 0000000000000124 RBX: 0000000000000034 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246 RBP: ffff880472fb3d88 R08: ffff88077fcd36c0 R09: 0000000000000001 R10: ffffffff8184bc48 R11: 0000000000000000 R12: ffff880273095800 R13: 0000000000000013 R14: ffff8802730a1810 R15: 0000000000000000 FS: 00007f694a20f720(0000) GS:ffff88077fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000000013c CR3: 000000067209b000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process set-cpus (pid: 3315, threadinfo ffff880472fb2000, task ffff880471fa0000) Stack: ffff880277b4c308 0000000000000003 ffff880472fb3d88 0000000000000005 0000000000000034 00000000ffffffd1 ffffffff81cadc70 ffff880472fb3e14 ffff880472fb3dc8 ffffffff8161f48d ffff880471fa0000 0000000000000034 Call Trace: [<ffffffff8161f48d>] notifier_call_chain+0x4d/0x70 [<ffffffff8107f1be>] __raw_notifier_call_chain+0xe/0x10 [<ffffffff81059d30>] __cpu_notify+0x20/0x40 [<ffffffff815fa251>] _cpu_down+0x81/0x270 [<ffffffff815fa477>] cpu_down+0x37/0x50 [<ffffffff815fd6a3>] store_online+0x63/0xc0 [<ffffffff813c7078>] dev_attr_store+0x18/0x30 [<ffffffff811f02cf>] sysfs_write_file+0xef/0x170 [<ffffffff81180443>] vfs_write+0xb3/0x180 [<ffffffff8118076a>] sys_write+0x4a/0x90 [<ffffffff816236a9>] system_call_fastpath+0x16/0x1b Code: 48 c7 c7 94 60 01 a0 44 0f b7 ac 10 ac 00 00 00 31 c0 e8 41 b7 5f e1 41 83 c5 02 49 63 c5 49 8b 44 c4 10 48 85 c0 74 56 45 31 ff <39> 58 18 75 4e eb 1f 49 63 d7 4c 89 f7 48 89 45 c8 48 6b d2 28 RIP [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] RSP <ffff880472fb3d48> CR2: 000000000000013c Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
-
Guenter Roeck authored
commit bdc71c9a upstream. CPU core ID is used to index the core_data[] array. The core ID is, however, not sequential; 10-core CPUS can have a core ID as high as 25. Increase the limit to 32 to be able to deal with current CPUs. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
-
Matthew Garrett authored
commit 54b3a4d3 upstream. Ben Hutchings pointed out that the validation in efivars was inadequate - most obviously, an entry with size 0 would server as a DoS against the kernel. Improve this based on his suggestions. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Matthew Garrett authored
commit fec6c20b upstream. A common flaw in UEFI systems is a refusal to POST triggered by a malformed boot variable. Once in this state, machines may only be restored by reflashing their firmware with an external hardware device. While this is obviously a firmware bug, the serious nature of the outcome suggests that operating systems should filter their variable writes in order to prevent a malicious user from rendering the machine unusable. Signed-off-by:
-
Tony Luck authored
commit b728a5c8 upstream. drivers/firmware/efivars.c:161: warning: ‘utf16_strlen’ defined but not used utf16_strlen() is only used inside CONFIG_PSTORE - make this "static inline" to shut the compiler up [thanks to hpa for the suggestion]. drivers/firmware/efivars.c:602: warning: initialization from incompatible pointer type Between v1 and v2 of this patch series we decided to make the "part" number unsigned - but missed fixing the stub version of efi_pstore_write() Acked-by:
Mike Waychison <mikew@google.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> [took the static part of the patch, not the pstore part, for 3.0-stable, to fix the compiler warning we had - gregkh] Signed-off-by:
-
Mike Waychison authored
commit a2940908 upstream. Fix the string functions in the efivars driver to be called utf16_* instead of utf8_* as the encoding is utf16, not utf8. As well, rename utf16_strlen to utf16_strnlen as it takes a maxlength argument and the name should be consistent with the standard C function names. utf16_strlen is still provided for convenience in a subsequent patch. Signed-off-by:
-
Matthew Garrett authored
commit 41b3254c upstream. More recent versions of the UEFI spec have added new attributes for variables. Add them. Signed-off-by:
-
Dan Williams authored
commit 7d1d8651 upstream. Normalize phy->attached_sas_addr to return a zero-address in the case when device-type == NO_DEVICE or the linkrate is invalid to handle expanders that put non-zero sas addresses in the discovery response: sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device) Reported-by:
Andrzej Jakowski <andrzej.jakowski@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Thomas Jackson authored
commit 1699490d upstream. If an expander reports 'PHY VACANT' for a phy index prior to the one that generated a BCN libsas fails rediscovery. Since a vacant phy is defined as a valid phy index that will never have an attached device just continue the search. Signed-off-by:
Thomas Jackson <thomas.p.jackson@intel.com> Signed-off-by:
-
Will Deacon authored
commit 6a1c5312 upstream. TPIDRURW is a user read/write register forming part of the group of thread registers in more recent versions of the ARM architecture (~v6+). Currently, the kernel does not touch this register, which allows tasks to communicate covertly by reading and writing to the register without context-switching affecting its contents. This patch clears TPIDRURW when TPIDRURO is updated via the set_tls macro, which is called directly from __switch_to. Since the current behaviour makes the register useless to userspace as far as thread pointers are concerned, simply clearing the register (rather than saving and restoring it) will not cause any problems to userspace. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Linus Torvalds authored
commit 64f371bc upstream. The autofs packet size has had a very unfortunate size problem on x86: because the alignment of 'u64' differs in 32-bit and 64-bit modes, and because the packet data was not 8-byte aligned, the size of the autofsv5 packet structure differed between 32-bit and 64-bit modes despite looking otherwise identical (300 vs 304 bytes respectively). We first fixed that up by making the 64-bit compat mode know about this problem in commit a32744d4 ("autofs: work around unhappy compat problem on x86-64"), and that made a 32-bit 'systemd' work happily on a 64-bit kernel because everything then worked the same way as on a 32-bit kernel. But it turned out that 'automount' had actually known and worked around this problem in user space, so fixing the kernel to do the proper 32-bit compatibility handling actually *broke* 32-bit automount on a 64-bit kernel, because it knew that the packet sizes were wrong and expected those incorrect sizes. As a result, we ended up reverting that compatibility mode fix, and thus breaking systemd again, in commit fcbf94b9. With both automount and systemd doing a single read() system call, and verifying that they get *exactly* the size they expect but using different sizes, it seemed that fixing one of them inevitably seemed to break the other. At one point, a patch I seriously considered applying from Michael Tokarev did a "strcmp()" to see if it was automount that was doing the operation. Ugly, ugly. However, a prettier solution exists now thanks to the packetized pipe mode. By marking the communication pipe as being packetized (by simply setting the O_DIRECT flag), we can always just write the bigger packet size, and if user-space does a smaller read, it will just get that partial end result and the extra alignment padding will simply be thrown away. This makes both automount and systemd happy, since they now get the size they asked for, and the kernel side of autofs simply no longer needs to care - it could pad out the packet arbitrarily. Of course, if there is some *other* user of autofs (please, please, please tell me it ain't so - and we haven't heard of any) that tries to read the packets with multiple writes, that other user will now be broken - the whole point of the packetized mode is that one system call gets exactly one packet, and you cannot read a packet in pieces. Tested-by:
Michael Tokarev <mjt@tls.msk.ru> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: David Miller <davem@davemloft.net> Cc: Ian Kent <raven@themaw.net> Cc: Thomas Meyer <thomas@m3y3r.de> Signed-off-by:
-
Linus Torvalds authored
commit 9883035a upstream. The actual internal pipe implementation is already really about individual packets (called "pipe buffers"), and this simply exposes that as a special packetized mode. When we are in the packetized mode (marked by O_DIRECT as suggested by Alan Cox), a write() on a pipe will not merge the new data with previous writes, so each write will get a pipe buffer of its own. The pipe buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn will tell the reader side to break the read at that boundary (and throw away any partial packet contents that do not fit in the read buffer). End result: as long as you do writes less than PIPE_BUF in size (so that the pipe doesn't have to split them up), you can now treat the pipe as a packet interface, where each read() system call will read one packet at a time. You can just use a sufficiently big read buffer (PIPE_BUF is sufficient, since bigger than that doesn't guarantee atomicity anyway), and the return value of the read() will naturally give you the size of the packet. NOTE! We do not support zero-sized packets, and zero-sized reads and writes to a pipe continue to be no-ops. Also note that big packets will currently be split at write time, but that the size at which that happens is not really specified (except that it's bigger than PIPE_BUF). Currently that limit is the system page size, but we might want to explicitly support bigger packets some day. The main user for this is going to be the autofs packet interface, allowing us to stop having to care so deeply about exact packet sizes (which have had bugs with 32/64-bit compatibility modes). But user space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will fail with an EINVAL on kernels that do not support this interface. Tested-by:
-
Laurent Pinchart authored
commit 6f6543f5 upstream. The field is used to pass the UVC request data length, but can also be used to signal an error when setting it to a negative value. Switch from unsigned int to __s32. Reported-by:
Fernandez Gonzalo <gfernandez@copreci.es> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Alan Stern authored
commit c85dcdac upstream. This patch (as1539) fixes a minor bug in the mass-storage gadget drivers. When an unknown command is received, the error code sent back is "Invalid Field in CDB" rather than "Invalid Command". This is because the bitmask of CDB bytes allowed to be nonzero is incorrect. When handling an unknown command, we don't care which command bytes are nonzero. All the bits in the mask should be set, not just eight of them. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Alan Stern authored
commit 151b6128 upstream. This patch (as1545) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. This fixes Bugzilla #42728. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Tested-by:
Andrey Rahmatullin <wrar@wrar.name> Tested-by:
Oleksij Rempel (fishor) <bug-track@fisher-privat.net> Signed-off-by:
-
Oliver Neukum authored
commit 5c22837a upstream. This patch fixes a race whereby a pointer to a buffer would be overwritten while the buffer was in use leading to a double free and a memory leak. This causes crashes. This bug was introduced in 2.6.34 Signed-off-by:
Oliver Neukum <oneukum@suse.de> Tested-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit d39514c1 which is e90fc3cb upstream as it causes oopses on some ppc systems. Reported-by:
Chen Peter-B29397 <B29397@freescale.com> Cc: Ramneek Mehresh <ramneek.mehresh@freescale.com> Cc: Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Al Viro authored
commit 04da6e9d upstream. nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Al Viro authored
commit 96f6f985 upstream. ..._want_write() returns -EROFS on failure, _not_ an NFS error value. Signed-off-by:
-
Eric Bénard authored
commit b8915282 upstream. This was broken by me in 37865fe9 ("mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhci") where more extensive tests would have shown that read or write of data to the card were failing (even if the partition table was correctly read). Signed-off-by:
Eric Bénard <eric@eukrea.com> Acked-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Alex Williamson authored
commit 32f6daad upstream. We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared. Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
David Miller authored
commit e88aa7bb upstream. The symbol table on x86-64 starts to have entries that have names like: _GLOBAL__sub_I_65535_0___mod_x86cpu_device_table They are of type STT_FUNCTION and this one had a length of 18. This matched the device ID validation logic and it barfed because the length did not meet the device type's criteria. -------------------- FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18. Fix definition of struct x86cpu_device_id in mod_devicetable.h -------------------- These are some kind of compiler tool internal stuff being emitted and not something we want to inspect in modpost's device ID table validation code. So skip the symbol if it is not of type STT_OBJECT. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Arend van Spriel authored
commit badc4f07 upstream. There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211. This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3. Tested-by:
Francesco Saverio Schiavarelli <fschiava@libero.it> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Brett Rudley <brudley@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Alan Stern authored
commit dc75ce9d upstream. This patch (as1542) changes the criterion ehci-hcd uses to tell when it needs to resume the controller's root hub. A resume is needed when a port status change is detected, obviously, but only if the root hub is currently suspended. Right now the driver tests whether the root hub is running, and that is not the correct test. In particular, if the controller has died then the root hub should not be restarted. In addition, some buggy hardware occasionally requires the root hub to be running and sending out SOF packets even while it is nominally supposed to be suspended. In the end, the test needs to be changed. Rather than checking whether the root hub is currently running, the driver will now check whether the root hub is currently suspended. This will yield the correct behavior in all cases. Signed-off-by:
-
Johannes Berg authored
commit 2b5f8b0b upstream. [backported by Ben Greear] The nl80211 handling code should ensure as much as it can that the interface is in a valid state, it can certainly ensure the interface is running. Not doing so can cause calls through mac80211 into the driver that result in warnings and unspecified behaviour in the driver. Reported-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Xi Wang authored
commit 44afb3a0 upstream. On 32-bit systems, a large args->num_cliprects from userspace via ioctl may overflow the allocation size, leading to out-of-bounds access. This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid allocation for execbuffer object list"). Signed-off-by:
Xi Wang <xi.wang@gmail.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Xi Wang authored
commit ed8cd3b2 upstream. On 32-bit systems, a large args->buffer_count from userspace via ioctl may overflow the allocation size, leading to out-of-bounds access. This vulnerability was introduced in commit 8408c282 ("drm/i915: First try a normal large kmalloc for the temporary exec buffers"). Signed-off-by:
-
