- 17 Mar, 2009 1 commit
-
-
Jeremy Fitzhardinge authored
Impact: fix crash on VMI (VMware) When we generate a call sequence for calling a paravirtualized function, we presume that the generated code is "call *0xXXXXX", which is a 6 byte opcode; this is larger than a normal direct call, and so we can patch a direct call over it. At the moment, however we give gcc enough rope to hang us by putting the address in a register and generating a two byte indirect-via-register call. Prevent this by explicitly dereferencing the function pointer and passing it into the asm as a constant. This prevents crashes in VMI, as it cannot handle unpatchable callsites. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Alok Kataria <akataria@vmware.com> LKML-Reference: <49BEEDC2.2070809@goop.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
-
- 14 Mar, 2009 1 commit
-
-
Pallipadi, Venkatesh authored
Impact: cleanup Add a new vm flag VM_PFN_AT_MMAP to identify a PFNMAP that is fully mapped with remap_pfn_range. Patch removes the overloading of VM_INSERTPAGE from the earlier patch. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Acked-by: Nick Piggin <npiggin@suse.de> LKML-Reference: <20090313233543.GA19909@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
- 13 Mar, 2009 1 commit
-
-
Pallipadi, Venkatesh authored
Impact: fix false positive PAT warnings - also fix VirtalBox hang Use of vma->vm_pgoff to identify the pfnmaps that are fully mapped at mmap time is broken. vm_pgoff is set by generic mmap code even for cases where drivers are setting up the mappings at the fault time. The problem was originally reported here: http://marc.info/?l=linux-kernel&m=123383810628583&w=2 Change is_linear_pfn_mapping logic to overload VM_INSERTPAGE flag along with VM_PFNMAP to mean full PFNMAP setup at mmap time. Problem also tracked at: http://bugzilla.kernel.org/show_bug.cgi?id=12800Reported-by: Thomas Hellstrom <thellstrom@vmware.com> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha>@intel.com> Cc: Nick Piggin <npiggin@suse.de> Cc: "ebiederm@xmission.com" <ebiederm@xmission.com> Cc: <stable@kernel.org> # only for 2.6.29.1, not .28 LKML-Reference: <20090313004527.GA7176@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
- 12 Mar, 2009 1 commit
-
-
Jan Beulich authored
Impact: fix potential oops during app-initiated LDT manipulation The underlying hypercall has differing argument requirements on 32- and 64-bit. Signed-off-by: Jan Beulich <jbeulich@novell.com> Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> LKML-Reference: <49B9061E.76E4.0078.0@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
- 11 Mar, 2009 14 commits
-
-
Stuart Bennett authored
This message was being incorrectly emitted when using gdb, so compile it out by default for now; there will be a better fix in v2.6.30. Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Stuart Bennett <stuart@freedesktop.org> Acked-by: Pekka Paalanen <pq@iki.fi> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: drm: fix EDID parser problem with positive/negative hsync/vsync
-
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpcLinus Torvalds authored
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: radeonfb/aty128fb: Disable broken early resume hook for PowerBooks hvc_console: Remove tty->low_latency on pseries backends powerpc: fix linkstation and storcenter compilation breakage powerpc/4xx: Enable SERIAL_OF support by default for Virtex platforms
-
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intelLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: drm/i915: fix 945 fence register writes for fence 8 and above. drm/i915: Protect active fences on i915 drm/i915: Check to see if we've pinned all available fences drm/i915: Check fence status on every pin. drm/i915: First recheck for an empty fence register. drm/i915: Fix bad \n in MTRR failure notice. drm/i915: Don't restore palettes through VGA registers. i915: add newline to i915_gem_object_pin failure msg drm: Return EINVAL on duplicate objects in execbuffer object list
-
Linus Torvalds authored
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: work around Fedora-11 x86-32 kernel failures on Intel Atom CPUs
-
OGAWA Hirofumi authored
On swapon() path, it has already i_mutex. So, this uses i_alloc_sem instead of it. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Reported-by: Laurent GUERBY <laurent@guerby.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Eric Anholt authored
The last 8 fence registers sit at a different offset, so when we went to set fence number 8 in the lower offset, we instead set PGETBL_CTL, and the GPU got all sorts of angry at us. fd.o bug #20567. Easily reproducible by running glxgears and killing it about 6 times. Signed-off-by: Eric Anholt <eric@anholt.net>
-
Chris Wilson authored
The i915 also uses the fence registers for GPU access to tiled buffers so we cannot reallocate one whilst it is on the active list. By performing a LRU scan of the fenced buffers we also avoid waiting the possibility of waiting on a pinned, or otherwise unusable, buffer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Ingo Molnar authored
Impact: work around boot crash Work around Intel Atom erratum AAH41 (probabilistically) - it's triggering in the field. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Tested-by: Kyle McMartin <kyle@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Wu Fengguang authored
Fix kpf_copy_bit(src,dst) to be kpf_copy_bit(dst,src) to match the actual call patterns, e.g. kpf_copy_bit(kflags, KPF_LOCKED, PG_locked). This misplacement of src/dst only affected reporting of PG_writeback, PG_reclaim and PG_buddy. For others kflags==uflags so not affected. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Wilson authored
We need to check and report if there are no available fences - or else we spin endlessly waiting for a buffer to magically unpin itself. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Chris Wilson authored
As we may steal the fence register of an unpinned buffer for another, every time we repin the buffer we need to recheck whether it needs to be allocated a fence. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Chris Wilson authored
If we wait upon a request and successfully unbind a buffer occupying a fence register, then that slot will be freed and cause a NULL derefrence upon rescanning. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Pantelis Koukousoulas authored
Comparing the layouts of struct detail_pixel_timing with x.org's struct detailed_timings and how those are handled, it appears that the hsync_positive and vsync_positive fields are backwards. This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=20019 for me. It was tested on 2 monitors, LG FLATRON L225WS 22" and a YAKUMO 17" for which more details are unknown. Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- 10 Mar, 2009 22 commits
-
-
Benjamin Herrenschmidt authored
radeonfb and aty128fb have a special hook called by the PowerMac platform code very very early on resume from sleep to bring the screen back. This is useful for debugging wakup problems, but unfortunately, this also became a source of problems of its own. The hook is called extremely early, with interrupts still off, and the code path involved with that code nowadays rely on things like taking mutexes, GFP_KERNEL allocations, etc... In addition, the driver now relies on the PCI core to restore the standard config space before calling resume which doesn't happen with this early code path. I'm keeping the code in but commented out along with a fixup call to pci_restore_state(). The reason is that I still want to make it easy to re-enable temporarily to track wake up problems, and it's possible that I can revive it at some stage if we make sleeping things save to call in early resume using a system state. In the meantime, this should fix several reported regressions. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
The hvcs and hvsi backends both set tty->low_latency to one, along with more or less scary comments regarding bugs or races that would happen if not doing so. However, they also both call tty_flip_buffer_push() in conexts where it's illegal to do so since some recent tty changes (or at least it may have been illegal always but it nows blows) when low_latency is set (ie, hard interrupt or with spinlock held and irqs disabled). This removes the setting for now to get them back to working condition, we'll have to address the races described in the comments separately if they are still an issue (some of this might have been fixed already). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
-
Samuel CUELLA authored
Prevent the kernel from being crashed by a divide-by-zero operation when supplied an incorrectly filled 'struct fb_var_screeninfo' from userland. Previously i810_main.c:1005 (i810_check_params) was using the global 'yres' symbol previously defined at i810_main.c:145 as a module parameter value holder (i810_main.c:2174). If i810fb is compiled-in or if this param doesn't get a default value, this direct usage leads to a divide-by-zero at i810_main.c:1005 (i810_check_params). The patch simply replace the 'yres' global, perhaps undefined symbol usage by a given parameter structure lookup. This problem occurs with directfb, mplayer -vo fbdev, SDL library. It was also reported ( but non solved ) at: http://mail.directfb.org/pipermail/directfb-dev/2008-March/004050.htmlSigned-off-by: Samuel CUELLA <samuel.cuella@supinfo.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Steven King authored
There isn't any mcfqspi.h in the tree, and without it everything inside the #ifdef CONFIG_SPI is uncompilable. Signed-off-by: Steven King <sfking@fdwdc.com> Acked-by: Greg Ungerer <gerg@snapgear.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Steven King authored
Signed-off-by: Steven King <sfking@fdwdc.com> Acked-by: Greg Ungerer <gerg@snapgear.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Paul E. McKenney authored
Update the RCU documentation to call out the need for callers of primitives like call_rcu() and synchronize_rcu() to prevent subsequent RCU readers from hazard. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Dhaval Giani authored
We were returning early in the sysfs directory cleanup function if the user belonged to a non init usernamespace. Due to this a lot of the cleanup was not done and we were left with a leak. Fix the leak. Reported-by: Serge Hallyn <serue@linux.vnet.ibm.com> Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com> Acked-by: Serge Hallyn <serue@us.ibm.com> Tested-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Atsushi Nemoto authored
commit e480814f ("[MTD] [MAPS] physmap: fix wrong free and del_mtd_{partition,device}") introduces a NULL pointer dereference in physmap_flash_remove when called from the error path in physmap_flash_probe (if map_probe failed). Call del_mtd_{partition,device} only if info->cmtd was not NULL. Reported-by: pHilipp Zabel <philipp.zabel@gmail.com> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: David Woodhouse <dwmw2@infradead.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Lubomir Rintel authored
When GTT size is equal to amount of video memory, the amount of GTT entries is computed lower than zero, which is invalid and leads to off-by-one error in intel_i915_configure() Originally posted here: http://bugzilla.kernel.org/show_bug.cgi?id=12539 http://bugzilla.redhat.com/show_bug.cgi?id=445592Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Cc: Lubomir Rintel <lkundrak@v3.sk> Cc: Dave Airlie <airlied@linux.ie> Reviewed-by: Eric Anholt <eric@anholt.net> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Will Newton authored
Commit 771999b6 ("[MTD] DataFlash: bugfix, binary page sizes now handled") broke support for probing AT45DB321C flash chips. These chips do not support the "page size" status bit, so if we match the JEDEC id return early. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Will Newton <will.newton@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Paul E. McKenney authored
Fix a problem in the IDR system, where an idr_remove_all() hands a data element to call_rcu() (via free_layer()) before making that data element inaccessible to new readers. This is very bad, and results in readers still having a reference to this data element at the end of the grace period. Tests on large machines that concurrently map and unmap user-space memory within the same multithreaded process result in crashes within about five minutes. Applying this patch increases the kernel's longevity to the three-to-eight-hour range. There appear to be other similar problems in idr_get_empty_slot() and sub_remove(), but I fixed the easy one in idr_remove_all() first. It is therefore no surprise that failures still occur. Located-by: Milton Miller II <miltonm@austin.ibm.com> Tested-by: Milton Miller II <miltonm@austin.ibm.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Alexey Dobriyan authored
Very annoying when working with containters. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Yinghai Lu authored
Impact: fix bug to make agp work with dri Jeffrey reported that dri does work with 64bit, but doesn't work with 32bit it turns out NB aperture is 32M, aperture on agp is 128M 64bit is using 64M for vaidation for 64 iommu/gart 32bit is only using 32M..., and will not update the nb aperture. So try to compare nb apterture and agp apterture before leaving not touch nb aperture. Reported-by: Jeffrey Trull <jetrull@sbcglobal.net> Tested-by: Jeffrey Trull <jetrull@sbcglobal.net> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Dave Airlie <airlied@linux.ie> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Alexey Dobriyan authored
* ->put_char changes * HIGHMEM is bogus it seems, there is no kmap_atomic() et al * some includes Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Acked-by: Chris Zankel <zankel@tensilica.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Darrick J. Wong authored
The adt7468 chip supports VRM10 sensors just like the adt7463; add a missing check for it. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Darrick J. Wong authored
The verstep check in the lm85 driver fails because the upper nibble of the version register is 0x7, not 0x6, on the adt7468 chip. Probing of all adt7468s was broken by 69fc1feb ("hwmon: (lm85) Rework the device detection"), and this patch fixes that. Also add in a missing i2c_device_id that accidentally got dropped from the original patch. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Randy Dunlap authored
The COMPAT_BRK kconfig symbol does not depend on EMBEDDED, but it is in the midst of the EMBEDDED menu symbols, so it mucks up the EMBEDDED menu. Fix by moving it to just after all of the EMBEDDED menu symbols. Also, ANON_INODES has a similar problem, so move it to just above the EMBEDDED menu items since it is used in the EMBEDDED menu. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Roel Kluin authored
get_nid_for_pfn() returns int Presumably the (nid < 0) case has never happened. We do know that it is happening on one system while creating a symlink for a memory section so it should also happen on the same system if unregister_mem_sect_under_nodes() were called to remove the same symlink. The test was actually added in response to a problem with an earlier version reported by Yasunori Goto where one or more of the leading pages of a memory section on the 2nd node of one of his systems was uninitialized because I believe they coincided with a memory hole. That earlier version did not ignore uninitialized pages and determined the nid by considering only the 1st page of each memory section. This caused the symlink to the 1st memory section on the 2nd node to be incorrectly created in /sys/devices/system/node/node0 instead of /sys/devices/system/node/node1. The problem was fixed by adding the test to skip over uninitialized pages. I suspect we have not seen any reports of the non-removal of a symlink due to the incorrect declaration of the nid variable in unregister_mem_sect_under_nodes() because - systems where a memory section could have an uninitialized range of leading pages are probably rare. - memory remove is probably not done very frequently on the systems that are capable of demonstrating the problem. - lingering symlink(s) that should have been removed may have simply gone unnoticed. [garyhade@us.ibm.com: wrote changelog] Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Eric Anholt authored
Signed-off-by: Eric Anholt <eric@anholt.net>
-
Pierre Willenbrock authored
The VGA registers just hit the pipe registers that we already set through MMIO. This fixes strange colors on resume. Signed-off-by: Pierre Willenbrock <pierre@pirsoft.de> Signed-off-by: Eric Anholt <eric@anholt.net>
-
Kyle McMartin authored
Prevents formatting nasty as below: [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_gem_evict_something] *ERROR* inactive empty 1 request empty 1 flushing empty 1 Signed-off-by: Kyle McMartin <kyle@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
-