- 09 Dec, 2010 40 commits
-
-
Stefan Richter authored
commit 137d9ebf upstream. If a device exposes a sparsely populated configuration ROM, firewire-core's sysfs interface and character device file interface showed random data in the gaps between config ROM blocks. Fix this by zero-initialization of the config ROM reader's scratch buffer. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: maximilian attems <max@stro.at> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Stefan Richter authored
commit 9cac00b8 upstream. A userspace client got to see uninitialized stack-allocated memory if it specified an _IOC_READ type of ioctl and an argument size larger than expected by firewire-core's ioctl handlers (but not larger than the core's union ioctl_arg). Fix this by clearing the requested buffer size to zero, but only at _IOR ioctls. This way, there is almost no runtime penalty to legitimate ioctls. The only legitimate _IOR is FW_CDEV_IOC_GET_CYCLE_TIMER with 12 or 16 bytes to memset. [Another way to fix this would be strict checking of argument size (and possibly direction) vs. command number. However, we then need a lookup table, and we need to allow for slight size deviations in case of 32bit userland on 64bit kernel.] Reported-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
maximilian attems <max@stro.at> Signed-off-by:
-
Ben Hutchings authored
commit c8770e7b upstream. We now use load_gs_index() to load gs safely; unfortunately this also changes MSR_KERNEL_GS_BASE, which we managed separately. This resulted in confusion and breakage running 32-bit host userspace on a 64-bit kernel. Fix by - saving guest MSR_KERNEL_GS_BASE before we we reload the host's gs - doing the host save/load unconditionally, instead of only when in guest long mode Things can be cleaned up further, but this is the minmal fix for now. Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> [bwh: Backport to 2.6.32] Signed-off-by:
-
Vasiliy Kulikov authored
commit 97e69aa6 upstream. Structures kvm_vcpu_events, kvm_debugregs, kvm_pit_state2 and kvm_clock_data are copied to userland with some padding and reserved fields unitialized. It leads to leaking of contents of kernel stack memory. We have to initialize them to zero. In patch v1 Jan Kiszka suggested to fill reserved fields with zeros instead of memset'ting the whole struct. It makes sense as these fields are explicitly marked as padding. No more fields need zeroing. Signed-off-by:
Vasiliy Kulikov <segooon@gmail.com> Signed-off-by:
-
Gleb Natapov authored
There is a bug in KVM that can be used to crash a host on Intel machines. If emulator is tricked into emulating mov to/from DR instruction it causes NULL pointer dereference on VMX since kvm_x86_ops->(set|get)_dr are not initialized. Recently this is not exploitable from guest userspace, but malicious guest kernel can trigger it easily. CVE-2010-0435 On upstream bug was fixed differently around 2.6.34. Signed-off-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
-
Jiri Slaby authored
commit 7f90cfc5 upstream. When a concrete ldisc open fails in tty_ldisc_open, we forget to clear TTY_LDISC_OPEN. This causes a false warning on the next ldisc open: WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38() Hardware name: System Product Name Modules linked in: ... Pid: 5251, comm: a.out Tainted: G W 2.6.32-5-686 #1 Call Trace: [<c1030321>] ? warn_slowpath_common+0x5e/0x8a [<c1030357>] ? warn_slowpath_null+0xa/0xc [<c119311c>] ? tty_ldisc_open+0x26/0x38 [<c11936c5>] ? tty_set_ldisc+0x218/0x304 ... So clear the bit when failing... Introduced in c65c9bc3 (tty: rewrite the ldisc locking) back in 2.6.31-rc1. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Reported-by:
Sergey Lapin <slapin@ossfans.org> Tested-by:
-
Philippe Rétornaz authored
commit 1c95ba1e upstream. A kernel BUG when bluetooth rfcomm connection drop while the associated serial port is open is sometime triggered. It seems that the line discipline can disappear between the tty_ldisc_put and tty_ldisc_get. This patch fall back to the N_TTY line discipline if the previous discipline is not available anymore. Signed-off-by:
Philippe Retornaz <philippe.retornaz@epfl.ch> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Jiri Slaby authored
commit 100eeae2 upstream. It was removed in 65b77046 (tty-ldisc: turn ldisc user count into a proper refcount), but we need to wait for last user to quit the ldisc before we close it in tty_set_ldisc. Otherwise weird things start to happen. There might be processes waiting in tty_read->n_tty_read on tty->read_wait for input to appear and at that moment, a change of ldisc is fatal. n_tty_close is called, it frees read_buf and the waiting process is still in the middle of reading and goes nuts after it is woken. Previously we prevented close to happen when others are in ldisc ops by tty_ldisc_wait_idle in tty_set_ldisc. But the commit above removed that. So revoke the change and test whether there is 1 user (=we), and allow the close then. We can do that without ldisc/tty locks, because nobody else can open the device due to TTY_LDISC_CHANGING bit set, so we in fact wait for everybody to leave. I don't understand why tty_ldisc_lock would be needed either when the counter is an atomic variable, so this is a lockless tty_ldisc_wait_idle. On the other hand, if we fail to wait (timeout or signal), we have to reenable the halted ldiscs, so we take ldisc lock and reuse the setup path at the end of tty_set_ldisc. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Tested-by:
Sebastian Andrzej Siewior <bigeasy@breakpoint.cc> LKML-Reference: <20101031104136.GA511@Chamillionaire.breakpoint.cc> LKML-Reference: <1287669539-22644-1-git-send-email-jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Jiri Olsa authored
commit e045fec4 upstream. There's a small window inside the flush_to_ldisc function, where the tty is unlocked and calling ldisc's receive_buf function. If in this window new buffer is added to the tty, the processing might never leave the flush_to_ldisc function. This scenario will hog the cpu, causing other tty processing starving, and making it impossible to interface the computer via tty. I was able to exploit this via pty interface by sending only control characters to the master input, causing the flush_to_ldisc to be scheduled, but never actually generate any output. To reproduce, please run multiple instances of following code. - SNIP #define _XOPEN_SOURCE #include <stdlib.h> #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> int main(int argc, char **argv) { int i, slave, master = getpt(); char buf[8192]; sprintf(buf, "%s", ptsname(master)); grantpt(master); unlockpt(master); slave = open(buf, O_RDWR); if (slave < 0) { perror("open slave failed"); return 1; } for(i = 0; i < sizeof(buf); i++) buf[i] = rand() % 32; while(1) { write(master, buf, sizeof(buf)); } return 0; } - SNIP The attached patch (based on -next tree) fixes this by checking on the tty buffer tail. Once it's reached, the current work is rescheduled and another could run. Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Prarit Bhargava authored
commit 303fc087 upstream. Fix panic seen on some IBM and HP systems on 2.6.32-rc6: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8120bf3f>] find_next_bit+0x77/0x9c [...] [<ffffffff8120bbde>] cpumask_next_and+0x2e/0x3b [<ffffffff81225c62>] pci_device_probe+0x8e/0xf5 [<ffffffff812b9be6>] ? driver_sysfs_add+0x47/0x6c [<ffffffff812b9da5>] driver_probe_device+0xd9/0x1f9 [<ffffffff812b9f1d>] __driver_attach+0x58/0x7c [<ffffffff812b9ec5>] ? __driver_attach+0x0/0x7c [<ffffffff812b9298>] bus_for_each_dev+0x54/0x89 [<ffffffff812b9b4f>] driver_attach+0x19/0x1b [<ffffffff812b97ae>] bus_add_driver+0xd3/0x23d [<ffffffff812ba1e7>] driver_register+0x98/0x109 [<ffffffff81225ed0>] __pci_register_driver+0x63/0xd3 [<ffffffff81072776>] ? up_read+0x26/0x2a [<ffffffffa0081000>] ? k8temp_init+0x0/0x20 [k8temp] [<ffffffffa008101e>] k8temp_init+0x1e/0x20 [k8temp] [<ffffffff8100a073>] do_one_initcall+0x6d/0x185 [<ffffffff8108d765>] sys_init_module+0xd3/0x236 [<ffffffff81011ac2>] system_call_fastpath+0x16/0x1b I put in a printk and commented out the set_dev_node() call when and got this output: quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x0 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x1 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x2 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x3 I.e. the issue appears to be that the HW has set val to a valid value, however, the system is only configured for a single node -- 0, the others are offline. Check to see if the node is actually online before setting the numa node for an AMD northbridge in quirk_amd_nb_node(). Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Cc: bhavna.sarathy@amd.com Cc: jbarnes@virtuousgeek.org Cc: andreas.herrmann3@amd.com LKML-Reference: <20091112180933.12532.98685.sendpatchset@prarit.bos.redhat.com> [ v2: clean up the code and add comments ] Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Justin Maggard authored
commit c26a44ed upstream. When trying to grow an array by enlarging component devices, rdev_size_store() expects the return value of rdev_size_change() to be in sectors, but the actual value is returned in KBs. This functionality was broken by commit dd8ac336 so this patch is suitable for any kernel since 2.6.30. Signed-off-by:
Justin Maggard <jmaggard10@gmail.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
commit 8f9e0ee3 upstream. Commit 4044ba58 supposedly fixed a problem where if a raid1 with just one good device gets a read-error during recovery, the recovery would abort and immediately restart in an infinite loop. However it depended on raid1_remove_disk removing the spare device from the array. But that does not happen in this case. So add a test so that in the 'recovery_disabled' case, the device will be removed. This suitable for any kernel since 2.6.29 which is when recovery_disabled was introduced. Reported-by:
Sebastian Färber <faerber@gmail.com> Signed-off-by:
-
Tyler Hicks authored
commit 2e21b3f1 upstream. eCryptfs was passing the LOOKUP_OPEN flag through to the lower file system, even though ecryptfs_create() doesn't support the flag. A valid filp for the lower filesystem could be returned in the nameidata if the lower file system's create() function supported LOOKUP_OPEN, possibly resulting in unencrypted writes to the lower file. However, this is only a potential problem in filesystems (FUSE, NFS, CIFS, CEPH, 9p) that eCryptfs isn't known to support today. https://bugs.launchpad.net/ecryptfs/+bug/641703 Reported-by: Kevin Buhr Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
-
Florian Tobias Schandinat authored
commit efd4f639 upstream. The colour was written to a wrong register for fillrect operations. This sometimes caused empty console space (for example after 'clear') to have a different colour than desired. Fix this by writing to the correct register. Many thanks to Daniel Drake and Jon Nettleton for pointing out this issue and pointing me in the right direction for the fix. Fixes http://dev.laptop.org/ticket/9323Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Daniel Drake <dsd@laptop.org> Cc: Jon Nettleton <jon.nettleton@gmail.com> Signed-off-by:
-
Graham Gower authored
commit 1e0ad288 upstream. When all VT's are in use, VT_OPENQRY casts -1 to unsigned char before returning it to userspace as an int. VT255 is not the next available console. Signed-off-by:
Graham Gower <graham.gower@gmail.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Ben Hutchings authored
commit 66c68bcc upstream. NETIF_F_HW_CSUM indicates the ability to update an TCP/IP-style 16-bit checksum with the checksum of an arbitrary part of the packet data, whereas the FCoE CRC is something entirely different. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dan Rosenberg authored
commit 982f7c2b upstream. The semctl syscall has several code paths that lead to the leakage of uninitialized kernel stack memory (namely the IPC_INFO, SEM_INFO, IPC_STAT, and SEM_STAT commands) during the use of the older, obsolete version of the semid_ds struct. The copy_semid_to_user() function declares a semid_ds struct on the stack and copies it back to the user without initializing or zeroing the "sem_base", "sem_pending", "sem_pending_last", and "undo" pointers, allowing the leakage of 16 bytes of kernel stack memory. The code is still reachable on 32-bit systems - when calling semctl() newer glibc's automatically OR the IPC command with the IPC_64 flag, but invoking the syscall directly allows users to use the older versions of the struct. Signed-off-by:
Dan Rosenberg <dan.j.rosenberg@gmail.com> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 3af54c9b upstream. The shmid_ds structure is copied to userland with shm_unused{,2,3} fields unitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
-
Dan Rosenberg authored
commit 03145beb upstream. This takes care of leaking uninitialized kernel stack memory to userspace from non-zeroed fields in structs in compat ipc functions. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Jeremy Fitzhardinge authored
commit 31e323cc upstream. Xen will shoot all the VCPUs when we do a shutdown hypercall, so there's no need to do it manually. In any case it will fail because all the IPI irqs have been pulled down by this point, so the cross-CPU calls will simply hang forever. Until change 76fac077 the function calls were not synchronously waited for, so this wasn't apparent. However after that change the calls became synchronous leading to a hang on shutdown on multi-VCPU guests. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Alok Kataria <akataria@vmware.com> Signed-off-by:
-
Ian Campbell authored
commit b0097ade upstream. All event channels startbound to VCPU 0 so ensure that cpu_evtchn_mask is initialised to reflect this. Otherwise there is a race after registering an event channel but before the affinity is explicitly set where the event channel can be delivered. If this happens then the event channel remains pending in the L1 (evtchn_pending) array but is cleared in L2 (evtchn_pending_sel), this means the event channel cannot be reraised until another event channel happens to trigger the same L2 entry on that VCPU. sizeof(cpu_evtchn_mask(0))==sizeof(unsigned long*) which is not correct, and causes only the first 32 or 64 event channels (depending on architecture) to be initially bound to VCPU0. Use sizeof(struct cpu_evtchn_s) instead. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Robin@sgi.com authored
commit c22c7aef upstream. UV hardware defines 256 memory protection regions versus the baseline 64 with increasing size for the SN2 ia64. This was overlooked when XPC was modified to accomodate both UV and SN2. Without this patch, a user could reconfigure their existing system and suddenly disable cross-partition communications with no indication of what has gone wrong. It also prevents larger configurations from using cross-partition communication. Signed-off-by:
Robin Holt <holt@sgi.com> Signed-off-by:
-
Daniel Klaffenbach authored
commit 1d8638d4 upstream. Add new vendor for Broadcom 4318. Signed-off-by:
Daniel Klaffenbach <danielklaffenbach@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Tejun Heo authored
commit 1529c69a upstream. IDE mode of MCP89 on MBP 7,1 doesn't set DMA enable bits in the BMDMA status register. Make the following changes to work around the problem. * Instead of using hard coded 1 in id->driver_data as class code match, use ATA_GEN_CLASS_MATCH and carry the matched id in host->private_data. * Instead of matching PCI_VENDOR_ID_CENATEK, use ATA_GEN_FORCE_DMA flag in id instead. * Add ATA_GEN_FORCE_DMA to the id entry of MBP 7,1. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Peer Chen <pchen@nvidia.com> Reported-by:
Anders Østhus <grapz666@gmail.com> Reported-by:
Andreas Graf <andreas_graf@csgraf.de> Reported-by:
Benoit Gschwind <gschwind@gnu-log.net> Reported-by:
Damien Cassou <damien.cassou@gmail.com> Reported-by: tixetsal@juno.com Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by:
-
Tejun Heo authored
commit c6353b45 upstream. For yet unknown reason, MCP89 on MBP 7,1 doesn't work w/ ahci under linux but the controller doesn't require explicit mode setting and works fine with ata_generic. Make ahci ignore the controller on MBP 7,1 and let ata_generic take it for now. Reported in bko#15923. https://bugzilla.kernel.org/show_bug.cgi?id=15923 NVIDIA is investigating why ahci mode doesn't work. Signed-off-by:
-
KAMEZAWA Hiroyuki authored
commit 572438f9 upstream. page_order() is called by memory hotplug's user interface to check the section is removable or not. (is_mem_section_removable()) It calls page_order() withoug holding zone->lock. So, even if the caller does if (PageBuddy(page)) ret = page_order(page) ... The caller may hit BUG_ON(). For fixing this, there are 2 choices. 1. add zone->lock. 2. remove BUG_ON(). is_mem_section_removable() is used for some "advice" and doesn't need to be 100% accurate. This is_removable() can be called via user program.. We don't want to take this important lock for long by user's request. So, this patch removes BUG_ON(). Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by:
Wu Fengguang <fengguang.wu@intel.com> Acked-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Mel Gorman <mel@csn.ul.ie> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
commit f8f72ad5 upstream. scan_lru_pages returns pfn. So, it's type should be "unsigned long" not "int". Note: I guess this has been work until now because memory hotplug tester's machine has not very big memory.... physical address < 32bit << PAGE_SHIFT. Reported-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
Jean Delvare authored
commit fa7a5797 upstream. The ADT7468 uses the same frequency table as the ADT7463. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Darrick J. Wong <djwong@us.ibm.com> Acked-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
-
Eric Dumazet authored
commit 800416f7 upstream. When a node contains only HighMem memory, slab_node(MPOL_BIND) dereferences a NULL pointer. [ This code seems to go back all the way to commit 19770b32: "mm: filter based on a nodemask as well as a gfp_mask". Which was back in April 2008, and it got merged into 2.6.26. - Linus ] Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Christoph Lameter <cl@linux.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Richard Weinberger authored
commit 482db6df upstream. This fixes a issue which was introduced by fe2cc53e ("uml: track and make up lost ticks"). timeval_to_ns() returns long long and not int. Due to that UML's timer did not work properlt and caused timer freezes. Signed-off-by:
Richard Weinberger <richard@nod.at> Acked-by:
Pekka Enberg <penberg@kernel.org> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Richard Weinberger authored
commit 6915e04f upstream. The linker script cleanup that I did in commit 5d150a97 ("um: Clean up linker script using standard macros.") (2.6.32) accidentally introduced an ALIGN(PAGE_SIZE) when converting to use INIT_TEXT_SECTION; Richard Weinberger reported that this causes the kernel to segfault with CONFIG_STATIC_LINK=y. I'm not certain why this extra alignment is a problem, but it seems likely it is because previously __init_begin = _stext = _text = _sinittext and with the extra ALIGN(PAGE_SIZE), _sinittext becomes different from the rest. So there is likely a bug here where something is assuming that _sinittext is the same as one of those other symbols. But reverting the accidental change fixes the regression, so it seems worth committing that now. Signed-off-by:
Tim Abbott <tabbott@ksplice.com> Reported-by:
-
Masanori ITOH authored
commit 8474b591 upstream. WARNING: at lib/list_debug.c:26 __list_add+0x3f/0x81() Hardware name: Express5800/B120a [N8400-085] list_add corruption. next->prev should be prev (ffffffff81a7ea00), but was dead000000200200. (next=ffff88080b872d58). Modules linked in: aoe ipt_MASQUERADE iptable_nat nf_nat autofs4 sunrpc bridge 8021q garp stp llc ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_round_robin dm_multipath kvm_intel kvm uinput lpfc scsi_transport_fc igb ioatdma scsi_tgt i2c_i801 i2c_core dca iTCO_wdt iTCO_vendor_support pcspkr shpchp megaraid_sas [last unloaded: aoe] Pid: 54, comm: events/3 Tainted: G W 2.6.34-vanilla1 #1 Call Trace: [<ffffffff8104bd77>] warn_slowpath_common+0x7c/0x94 [<ffffffff8104bde6>] warn_slowpath_fmt+0x41/0x43 [<ffffffff8120fd2e>] __list_add+0x3f/0x81 [<ffffffff81212a12>] __percpu_counter_init+0x59/0x6b [<ffffffff810d8499>] bdi_init+0x118/0x17e [<ffffffff811f2c50>] blk_alloc_queue_node+0x79/0x143 [<ffffffff811f2d2b>] blk_alloc_queue+0x11/0x13 [<ffffffffa02a931d>] aoeblk_gdalloc+0x8e/0x1c9 [aoe] [<ffffffffa02aa655>] aoecmd_sleepwork+0x25/0xa8 [aoe] [<ffffffff8106186c>] worker_thread+0x1a9/0x237 [<ffffffffa02aa630>] ? aoecmd_sleepwork+0x0/0xa8 [aoe] [<ffffffff81065827>] ? autoremove_wake_function+0x0/0x39 [<ffffffff810616c3>] ? worker_thread+0x0/0x237 [<ffffffff810653ad>] kthread+0x7f/0x87 [<ffffffff8100aa24>] kernel_thread_helper+0x4/0x10 [<ffffffff8106532e>] ? kthread+0x0/0x87 [<ffffffff8100aa20>] ? kernel_thread_helper+0x0/0x10 It's because there is no initialization code for a list_head contained in the struct backing_dev_info under CONFIG_HOTPLUG_CPU, and the bug comes up when block device drivers calling blk_alloc_queue() are used. In case of me, I got them by using aoe. Signed-off-by:
Masanori Itoh <itoumsn@nttdata.co.jp> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
-
Richard A. Smith authored
commit 7cfbb294 upstream. When the driver was updated to be endian neutral (8e9c7716) the signed part of the s16 values was lost. This is because be16_to_cpu() returns an unsigned value. This patch casts the values back to a s16 number prior to the the implicit cast up to an int. Signed-off-by:
Richard A. Smith <richard@laptop.org> Signed-off-by:
Daniel Drake <dsd@laptop.org> Signed-off-by:
Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by:
-
Jiri Slaby authored
commit a56d5318 upstream. When the initialization code in hpet finds a memory resource and does not find an IRQ, it does not unmap the memory resource previously mapped. There are buggy BIOSes which report resources exactly like this and what is worse the memory region bases point to normal RAM. This normally would not matter since the space is not touched. But when PAT is turned on, ioremap causes the page to be uncached and sets this bit in page->flags. Then when the page is about to be used by the allocator, it is reported as: BUG: Bad page state in process md5sum pfn:3ed00 page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0 page flags: 0x20000001000000(uncached) Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1 Call Trace: [<ffffffff810df851>] bad_page+0xb1/0x100 [<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0 [<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640 [<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0 ... In this particular case: 1) HPET returns 3ed00000 as memory region base, but it is not in reserved ranges reported by the BIOS (excerpt): BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable) BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved) 2) there is no IRQ resource reported by HPET method. On the other hand, the Intel HPET specs (1.0a) says (3.2.5.1): _CRS ( // Report 1K of memory consumed by this Timer Block memory range consumed // Optional: only used if BIOS allocates Interrupts [1] IRQs consumed ) [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND Legacy 8254/Legacy RTC hardware still exists, the device objects associated with 8254 & RTC devices should not report IRQ0/IRQ8 as "consumed resources". So in theory we should check whether if it is the case and use those interrupts instead. Anyway the address reported by the BIOS here is bogus, so non-presence of IRQ doesn't mean the "optional" part in point 2). Since I got no reply previously, fix this by simply unmapping the space when IRQ is not found and memory region was mapped previously. It would be probably more safe to walk the resources again and unmap appropriately depending on type. But as we now use only ioremap for both 2 memory resource types, it is not necessarily needed right now. Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908Reported-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
-
Clemens Ladisch authored
commit 96e9694d upstream. Jaswinder Singh Rajput wrote: > By executing Documentation/timers/hpet_example.c > > for polling, I requested for 3 iterations but it seems iteration work > for only 2 as first expired time is always very small. > > # ./hpet_example poll /dev/hpet 10 3 > -hpet: executing poll > hpet_poll: info.hi_flags 0x0 > hpet_poll: expired time = 0x13 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x1868c > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x18645 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 Clearing the HPET interrupt enable bit disables interrupt generation but does not disable the timer, so the interrupt status bit will still be set when the timer elapses. If another interrupt arrives before the timer has been correctly programmed (due to some other device on the same interrupt line, or CONFIG_DEBUG_SHIRQ), this results in an extra unwanted interrupt event because the status bit is likely to be set from comparator matches that happened before the device was opened. Therefore, we have to ensure that the interrupt status bit is and stays cleared until we actually program the timer. Signed-off-by:
Jaswinder Singh Rajput <jaswinderlinux@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Bob Picco <bpicco@redhat.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 2018845b and 2018845b upstream merged together as it had to be backported by hand. They should not be writable by any user Reported-by:
-
Greg Kroah-Hartman authored
commit 515b4987 upstream. They should be writable by root, not readable. Doh, stupid me with the wrong flags. Reported-by:
Jonathan Cameron <jic23@cam.ac.uk> Cc: Jakub Schmidtke <sjakub@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 590b0b97 upstream. They should not be writable by any user Reported-by:
-
Kees Cook authored
commit ae6df5f9 upstream. Calling ETHTOOL_GRXCLSRLALL with a large rule_cnt will allocate kernel heap without clearing it. For the one driver (niu) that implements it, it will leave the unused portion of heap unchanged and copy the full contents back to userspace. Signed-off-by:
Kees Cook <kees.cook@canonical.com> Acked-by:
-
Thomas Backlund authored
commit b843e4ec upstream. When running make headers_install_all on x86_64 and make 3.82 I hit this: arch/microblaze/Makefile:80: *** mixed implicit and normal rules. Stop. make: *** [headers_install_all] Error 2 So split the rules to satisfy make 3.82. Signed-off-by:
Thomas Backlund <tmb@mandriva.org> Signed-off-by:
Michal Simek <monstr@monstr.eu> Signed-off-by:
-
