Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Sep 20, 2010
  1. @gregkh

    Linux 2.6.35.5

    gregkh authored
  2. @ickle @gregkh

    drm: Only decouple the old_fb from the crtc is we call mode_set*

    ickle authored gregkh committed
    commit 356ad3c upstream.
    
    Otherwise when disabling the output we switch to the new fb (which is
    likely NULL) and skip the call to mode_set -- leaking driver private
    state on the old_fb.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857
    Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @ickle @gregkh

    Revert "drm/i915: Allow LVDS on pipe A on gen4+"

    ickle authored gregkh committed
    commit 12e8ba2 upstream.
    
    This reverts commit 0f3ee80.
    
    Enabling LVDS on pipe A was causing excessive wakeups on otherwise idle
    systems due to i915 interrupts. So restrict the LVDS to pipe B once more,
    whilst the issue is properly diagnosed.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307
    Reported-and-tested-by: Enrico Bandiello <enban@postal.uv.es>
    Poked-by: Florian Mickler <florian@mickler.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    drm/i915: don't enable self-refresh on Ironlake

    Jesse Barnes authored gregkh committed
    commit dd8849c upstream.
    
    We don't know how to enable it safely, especially as outputs turn on and
    off.  When disabling LP1 we also need to make sure LP2 and 3 are already
    disabled.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29173
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29082
    Reported-by: Chris Lord <chris@linux.intel.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @ickle @gregkh

    drm/i915: Prevent double dpms on

    ickle authored gregkh committed
    commit 032d2a0 upstream.
    
    Arguably this is a bug in drm-core in that we should not be called twice
    in succession with DPMS_ON, however this is still occuring and we see
    FDI link training failures on the second call leading to the occassional
    blank display. For the time being ignore the repeated call.
    
    Original patch by Dave Airlie <airlied@redhat.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @danvet @gregkh

    drm/i915: overlay on gen2 can't address above 1G

    danvet authored gregkh committed
    commit 9f82d23 upstream.
    
    So set the coherent dma mask accordingly. This dma mask is only used
    for physical objects, so it won't really matter allocation-wise.
    
    Now this never really surfaced because sane 32bit kernels only have 1G
    of lowmem. But some eager testers (distros?) still carry around the patch
    to adjust lowmem via a kconfig option. And the kernel seems to favour
    high allocations on boot-up, hence the overlay blowing up reliably.
    
    Because the patch is tiny and nicely shows how broken gen2 is it's imho
    worth to merge despite the fact that mucking around with the lowmem/
    highmem division is (no longer) supported.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28318
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @ickle @gregkh

    drm/i915: Allocate the PCI resource for the MCHBAR

    ickle authored gregkh committed
    commit a25c25c upstream.
    
    We were failing when trying to allocate the resource for MMIO of the
    MCHBAR because we forgot to specify what type of resource we wanted.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @ickle @gregkh

    drm/i915/dp: Really try 5 times before giving up.

    ickle authored gregkh committed
    commit 4f7f7b7 upstream.
    
    Only stop trying if the aux channel sucessfully reports that the
    transmission was completed, otherwise try again. On the 5th failure,
    bail and report that something is amiss.
    
    This fixes a sporadic failure in reading the EDID for my external panel
    over DP.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @error27 @gregkh

    i915_gem: return -EFAULT if copy_to_user fails

    error27 authored gregkh committed
    commit c877cdc upstream.
    
    copy_to_user() returns the number of bytes remaining to be copied and
    I'm pretty sure we want to return a negative error code here.
    
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @error27 @gregkh

    i915: return -EFAULT if copy_to_user fails

    error27 authored gregkh committed
    commit 9927a40 upstream.
    
    copy_to_user returns the number of bytes remaining to be copied, but we
    want to return a negative error code here.  These are returned to
    userspace.
    
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    drm/radeon/kms/evergreen: fix backend setup

    Alex Deucher authored gregkh committed
    commit b741be8 upstream.
    
    This patch fixes rendering errors on some evergreen boards.
    Hardcoding the backend map is not an optimal solution, but
    a better fix is being worked on.
    
    Similar to the fix for rv740
    (6271901).
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=29986
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    drm/radeon/kms/evergreen: fix gpu hangs in userspace accel code

    Alex Deucher authored gregkh committed
    commit 7e7b41d upstream.
    
    These VGT regs need to be programmed via the ring rather than
    MMIO as on previous asics (r6xx/r7xx).
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    drm/radeon/kms: properly set crtc high base on r7xx

    Alex Deucher authored gregkh committed
    commit 9534787 upstream.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    drm/radeon/kms: force legacy pll algo for RV620 LVDS

    Alex Deucher authored gregkh committed
    commit f90087e upstream.
    
    There has been periodic evidence that LVDS, on at least some
    panels, prefers the dividers selected by the legacy pll algo.
    This patch forces the use of the legacy pll algo on RV620
    LVDS panels.  The old behavior (new pll algo) can be selected
    by setting the new_pll module parameter to 1.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=30029
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    drm/radeon/kms: force legacy pll algo for RV515 LVDS

    Alex Deucher authored gregkh committed
    commit 0d9958b upstream.
    
    There has been periodic evidence that LVDS, on at least some
    panels, prefers the dividers selected by the legacy pll algo.
    This patch forces the use of the legacy pll algo on RV515
    LVDS panels.  The old behavior (new pll algo) can be selected
    by setting the new_pll module parameter to 1.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @gregkh

    drm/i915: Enable MI_FLUSH on Sandybridge

    Zhenyu Wang authored gregkh committed
    commit a69ffdb upstream.
    
    MI_FLUSH is being deprecated, but still available on Sandybridge.
    Make sure it's enabled as userspace still uses MI_FLUSH.
    
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @gregkh

    drm/radeon/kms: fix a regression on r7xx AGP due to the HDP flush fix

    Alex Deucher authored gregkh committed
    commit 87cbf8f upstream.
    
    commit: 812d046
    drm/radeon/kms/r7xx: add workaround for hw issue with HDP flush
    breaks on AGP boards since there is no VRAM gart table.
    
    This patch fixes the issue by creating a VRAM scratch page so that
    can be used on both AGP and PCIE.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=29834
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @ickle @gregkh

    agp/intel: Promote warning about failure to setup flush to error.

    ickle authored gregkh committed
    commit df51e7a upstream.
    
    Make sure we always detect when we fail to correctly allocate the Isoch
    Flush Page and print an error to warn the user about the likely memory
    corruption that will result in invalid rendering or worse.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    SUNRPC: Fix race corrupting rpc upcall

    Trond Myklebust authored gregkh committed
    commit 5a67657 upstream.
    
    If rpc_queue_upcall() adds a new upcall to the rpci->pipe list just
    after rpc_pipe_release calls rpc_purge_list(), but before it calls
    gss_pipe_release (as rpci->ops->release_pipe(inode)), then the latter
    will free a message without deleting it from the rpci->pipe list.
    
    We will be left with a freed object on the rpc->pipe list.  Most
    frequent symptoms are kernel crashes in rpc.gssd system calls on the
    pipe in question.
    
    Reported-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    NFS: Fix a typo in nfs_sockaddr_match_ipaddr6

    Trond Myklebust authored gregkh committed
    commit b20d37c upstream.
    
    Reported-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    cifs: fix potential double put of TCP session reference

    Jeff Layton authored gregkh committed
    commit 460cf34 upstream.
    
    cifs_get_smb_ses must be called on a server pointer on which it holds an
    active reference. It first does a search for an existing SMB session. If
    it finds one, it'll put the server reference and then try to ensure that
    the negprot is done, etc.
    
    If it encounters an error at that point then it'll return an error.
    There's a potential problem here though. When cifs_get_smb_ses returns
    an error, the caller will also put the TCP server reference leading to a
    double-put.
    
    Fix this by having cifs_get_smb_ses only put the server reference if
    it found an existing session that it could use and isn't returning an
    error.
    
    Reviewed-by: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @enomsg @gregkh

    apm_power: Add missing break statement

    enomsg authored gregkh committed
    commit 1d22033 upstream.
    
    The missing break statement causes wrong capacity calculation for
    batteries that report energy.
    
    Reported-by: d binderman <dcb314@hotmail.com>
    Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @guillemj @gregkh

    hwmon: (f75375s) Do not overwrite values read from registers

    guillemj authored gregkh committed
    commit c3b327d upstream.
    
    All bits in the values read from registers to be used for the next
    write were getting overwritten, avoid doing so to not mess with the
    current configuration.
    
    Signed-off-by: Guillem Jover <guillem@hadrons.org>
    Cc: Riku Voipio <riku.voipio@iki.fi>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @guillemj @gregkh

    hwmon: (f75375s) Shift control mode to the correct bit position

    guillemj authored gregkh committed
    commit 96f3640 upstream.
    
    The spec notes that fan0 and fan1 control mode bits are located in bits
    7-6 and 5-4 respectively, but the FAN_CTRL_MODE macro was making the
    bits shift by 5 instead of by 4.
    
    Signed-off-by: Guillem Jover <guillem@hadrons.org>
    Cc: Riku Voipio <riku.voipio@iki.fi>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    hwmon: (emc1403) Remove unnecessary hwmon_device_unregister

    Yong Wang authored gregkh committed
    commit f17c811 upstream.
    
    It is unnecessary and wrong to call hwmon_device_unregister in error
    handling before hwmon_device_register is called.
    
    Signed-off-by: Yong Wang <yong.y.wang@intel.com>
    Reviewed-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    arm: fix really nasty sigreturn bug

    Al Viro authored gregkh committed
    commit 653d48b upstream.
    
    If a signal hits us outside of a syscall and another gets delivered
    when we are in sigreturn (e.g. because it had been in sa_mask for
    the first one and got sent to us while we'd been in the first handler),
    we have a chance of returning from the second handler to location one
    insn prior to where we ought to return.  If r0 happens to contain -513
    (-ERESTARTNOINTR), sigreturn will get confused into doing restart
    syscall song and dance.
    
    Incredible joy to debug, since it manifests as random, infrequent and
    very hard to reproduce double execution of instructions in userland
    code...
    
    The fix is simple - mark it "don't bother with restarts" in wrapper,
    i.e. set r8 to 0 in sys_sigreturn and sys_rt_sigreturn wrappers,
    suppressing the syscall restart handling on return from these guys.
    They can't legitimately return a restart-worthy error anyway.
    
    Testcase:
    	#include <unistd.h>
    	#include <signal.h>
    	#include <stdlib.h>
    	#include <sys/time.h>
    	#include <errno.h>
    
    	void f(int n)
    	{
    		__asm__ __volatile__(
    			"ldr r0, [%0]\n"
    			"b 1f\n"
    			"b 2f\n"
    			"1:b .\n"
    			"2:\n" : : "r"(&n));
    	}
    
    	void handler1(int sig) { }
    	void handler2(int sig) { raise(1); }
    	void handler3(int sig) { exit(0); }
    
    	main()
    	{
    		struct sigaction s = {.sa_handler = handler2};
    		struct itimerval t1 = { .it_value = {1} };
    		struct itimerval t2 = { .it_value = {2} };
    
    		signal(1, handler1);
    
    		sigemptyset(&s.sa_mask);
    		sigaddset(&s.sa_mask, 1);
    		sigaction(SIGALRM, &s, NULL);
    
    		signal(SIGVTALRM, handler3);
    
    		setitimer(ITIMER_REAL, &t1, NULL);
    		setitimer(ITIMER_VIRTUAL, &t2, NULL);
    
    		f(-513); /* -ERESTARTNOINTR */
    
    		write(1, "buggered\n", 9);
    		return 1;
    	}
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    x86: hpet: Work around hardware stupidity

    Thomas Gleixner authored gregkh committed
    commit 54ff7e5 upstream.
    
    This more or less reverts commits 08be979 (x86: Force HPET
    readback_cmp for all ATI chipsets) and 30a564b (x86, hpet: Restrict
    read back to affected ATI chipsets) to the status of commit 8da854c
    (x86, hpet: Erratum workaround for read after write of HPET
    comparator).
    
    The delta to commit 8da854c is mostly comments and the change from
    WARN_ONCE to printk_once as we know the call path of this function
    already.
    
    This needs really in depth explanation:
    
    First of all the HPET design is a complete failure. Having a counter
    compare register which generates an interrupt on matching values
    forces the software to do at least one superfluous readback of the
    counter register.
    
    While it is nice in theory to program "absolute" time events it is
    practically useless because the timer runs at some absurd frequency
    which can never be matched to real world units. So we are forced to
    calculate a relative delta and this forces a readout of the actual
    counter value, adding the delta and programming the compare
    register. When the delta is small enough we run into the danger that
    we program a compare value which is already in the past. Due to the
    compare for equal nature of HPET we need to read back the counter
    value after writing the compare rehgister (btw. this is necessary for
    absolute timeouts as well) to make sure that we did not miss the timer
    event. We try to work around that by setting the minimum delta to a
    value which is larger than the theoretical time which elapses between
    the counter readout and the compare register write, but that's only
    true in theory. A NMI or SMI which hits between the readout and the
    write can easily push us beyond that limit. This would result in
    waiting for the next HPET timer interrupt until the 32bit wraparound
    of the counter happens which takes about 306 seconds.
    
    So we designed the next event function to look like:
    
       match = read_cnt() + delta;
       write_compare_ref(match);
       return read_cnt() < match ? 0 : -ETIME;
    
    At some point we got into trouble with certain ATI chipsets. Even the
    above "safe" procedure failed. The reason was that the write to the
    compare register was delayed probably for performance reasons. The
    theory was that they wanted to avoid the synchronization of the write
    with the HPET clock, which is understandable. So the write does not
    hit the compare register directly instead it goes to some intermediate
    register which is copied to the real compare register in sync with the
    HPET clock. That opens another window for hitting the dreaded "wait
    for a wraparound" problem.
    
    To work around that "optimization" we added a read back of the compare
    register which either enforced the update of the just written value or
    just delayed the readout of the counter enough to avoid the issue. We
    unfortunately never got any affirmative info from ATI/AMD about this.
    
    One thing is sure, that we nuked the performance "optimization" that
    way completely and I'm pretty sure that the result is worse than
    before some HW folks came up with those.
    
    Just for paranoia reasons I added a check whether the read back
    compare register value was the same as the value we wrote right
    before. That paranoia check triggered a couple of years after it was
    added on an Intel ICH9 chipset. Venki added a workaround (commit
    8da854c) which was reading the compare register twice when the first
    check failed. We considered this to be a penalty in general and
    restricted the readback (thus the wasted CPU cycles) to the known to
    be affected ATI chipsets.
    
    This turned out to be a utterly wrong decision. 2.6.35 testers
    experienced massive problems and finally one of them bisected it down
    to commit 30a564b which spured some further investigation.
    
    Finally we got confirmation that the write to the compare register can
    be delayed by up to two HPET clock cycles which explains the problems
    nicely. All we can do about this is to go back to Venki's initial
    workaround in a slightly modified version.
    
    Just for the record I need to say, that all of this could have been
    avoided if hardware designers and of course the HPET committee would
    have thought about the consequences for a split second. It's out of my
    comprehension why designing a working timer is so hard. There are two
    ways to achieve it:
    
     1) Use a counter wrap around aware compare_reg <= counter_reg
        implementation instead of the easy compare_reg == counter_reg
    
        Downsides:
    
    	- It needs more silicon.
    
    	- It needs a readout of the counter to apply a relative
    	  timeout. This is necessary as the counter does not run in
    	  any useful (and adjustable) frequency and there is no
    	  guarantee that the counter which is used for timer events is
    	  the same which is used for reading the actual time (and
    	  therefor for calculating the delta)
    
        Upsides:
    
    	- None
    
      2) Use a simple down counter for relative timer events
    
        Downsides:
    
    	- Absolute timeouts are not possible, which is not a problem
    	  at all in the context of an OS and the expected
    	  max. latencies/jitter (also see Downsides of #1)
    
       Upsides:
    
    	- It needs less or equal silicon.
    
    	- It works ALWAYS
    
    	- It is way faster than a compare register based solution (One
    	  write versus one write plus at least one and up to four
    	  reads)
    
    I would not be so grumpy about all of this, if I would not have been
    ignored for many years when pointing out these flaws to various
    hardware folks. I really hate timers (at least those which seem to be
    designed by janitors).
    
    Though finally we got a reasonable explanation plus a solution and I
    want to thank all the folks involved in chasing it down and providing
    valuable input to this.
    
    Bisected-by: Nix <nix@esperi.org.uk>
    Reported-by: Artur Skawina <art.08.09@gmail.com>
    Reported-by: Damien Wyart <damien.wyart@free.fr>
    Reported-by: John Drescher <drescherjm@gmail.com>
    Cc: Venkatesh Pallipadi <venki@google.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
    Cc: Borislav Petkov <borislav.petkov@amd.com>
    Cc: stable@kernel.org
    Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @diwic @gregkh

    ALSA: HDA: Enable internal speaker on Dell M101z

    diwic authored gregkh committed
    commit 145a902 upstream.
    
    BugLink: http://launchpad.net/bugs/640254
    
    In some cases a magic processing coefficient is needed to enable
    the internal speaker on Dell M101z. According to Realtek, this
    processing coefficient is only present on ALC269vb.
    
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @gregkh

    x86-64, compat: Retruncate rax after ia32 syscall entry tracing

    Roland McGrath authored gregkh committed
    commit eefdca0 upstream.
    
    In commit d4d6715, we reopened an old hole for a 64-bit ptracer touching a
    32-bit tracee in system call entry.  A %rax value set via ptrace at the
    entry tracing stop gets used whole as a 32-bit syscall number, while we
    only check the low 32 bits for validity.
    
    Fix it by truncating %rax back to 32 bits after syscall_trace_enter,
    in addition to testing the full 64 bits as has already been added.
    
    Reported-by: Ben Hawkes <hawkes@sota.gen.nz>
    Signed-off-by: Roland McGrath <roland@redhat.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    compat: Make compat_alloc_user_space() incorporate the access_ok()

    H. Peter Anvin authored gregkh committed
    commit c41d68a upstream.
    
    compat_alloc_user_space() expects the caller to independently call
    access_ok() to verify the returned area.  A missing call could
    introduce problems on some architectures.
    
    This patch incorporates the access_ok() check into
    compat_alloc_user_space() and also adds a sanity check on the length.
    The existing compat_alloc_user_space() implementations are renamed
    arch_compat_alloc_user_space() and are used as part of the
    implementation of the new global function.
    
    This patch assumes NULL will cause __get_user()/__put_user() to either
    fail or access userspace on all architectures.  This should be
    followed by checking the return value of compat_access_user_space()
    for NULL in the callers, at which time the access_ok() in the callers
    can also be removed.
    
    Reported-by: Ben Hawkes <hawkes@sota.gen.nz>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Chris Metcalf <cmetcalf@tilera.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Acked-by: Ingo Molnar <mingo@elte.hu>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Tony Luck <tony.luck@intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James Bottomley <jejb@parisc-linux.org>
    Cc: Kyle McMartin <kyle@mcmartin.ca>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @gregkh

    x86-64, compat: Test %rax for the syscall number, not %eax

    H. Peter Anvin authored gregkh committed
    commit 36d001c upstream.
    
    On 64 bits, we always, by necessity, jump through the system call
    table via %rax.  For 32-bit system calls, in theory the system call
    number is stored in %eax, and the code was testing %eax for a valid
    system call number.  At one point we loaded the stored value back from
    the stack to enforce zero-extension, but that was removed in checkin
    d4d6715.  An actual 32-bit process
    will not be able to introduce a non-zero-extended number, but it can
    happen via ptrace.
    
    Instead of re-introducing the zero-extension, test what we are
    actually going to use, i.e. %rax.  This only adds a handful of REX
    prefixes to the code.
    
    Reported-by: Ben Hawkes <hawkes@sota.gen.nz>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Roland McGrath <roland@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @gregkh

    x86, tsc: Fix a preemption leak in restore_sched_clock_state()

    Peter Zijlstra authored gregkh committed
    commit 55496c8 upstream.
    
    Doh, a real life genuine preemption leak..
    
    This caused a suspend failure.
    
    Reported-bisected-and-tested-by-the-invaluable: Jeff Chua <jeff.chua.linux@gmail.com>
    Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Cc: Nico Schottelius <nico-linux-20100709@schottelius.org>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Florian Pritz <flo@xssn.at>
    Cc: Suresh Siddha <suresh.b.siddha@intel.com>
    Cc: Len Brown <lenb@kernel.org>
    sleep states
    LKML-Reference: <1284150773.402.122.camel@laptop>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @larrystevenwise @gregkh

    RDMA/cxgb3: Don't exceed the max HW CQ depth

    larrystevenwise authored gregkh committed
    commit dc4e96c upstream.
    
    The max depth supported by T3 is 64K entries.  This fixes a bug
    introduced in commit 9918b28 ("RDMA/cxgb3: Increase the max CQ
    depth") that causes stalls and possibly crashes in large MPI clusters.
    
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <rolandd@cisco.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @jmberg @gregkh

    wireless extensions: fix kernel heap content leak

    jmberg authored gregkh committed
    commit 42da2f9 upstream.
    
    Wireless extensions have an unfortunate, undocumented
    requirement which requires drivers to always fill
    iwp->length when returning a successful status. When
    a driver doesn't do this, it leads to a kernel heap
    content leak when userspace offers a larger buffer
    than would have been necessary.
    
    Arguably, this is a driver bug, as it should, if it
    returns 0, fill iwp->length, even if it separately
    indicated that the buffer contents was not valid.
    
    However, we can also at least avoid the memory content
    leak if the driver doesn't do this by setting the iwp
    length to max_tokens, which then reflects how big the
    buffer is that the driver may fill, regardless of how
    big the userspace buffer is.
    
    To illustrate the point, this patch also fixes a
    corresponding cfg80211 bug (since this requirement
    isn't documented nor was ever pointed out by anyone
    during code review, I don't trust all drivers nor
    all cfg80211 handlers to implement it correctly).
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  35. @linvjw @gregkh

    ath5k: check return value of ieee80211_get_tx_rate

    linvjw authored gregkh committed
    commit d8e1ba7 upstream.
    
    This avoids a NULL pointer dereference as reported here:
    
    	https://bugzilla.redhat.com/show_bug.cgi?id=625889
    
    When the WARN condition is hit in ieee80211_get_tx_rate, it will return
    NULL.  So, we need to check the return value and avoid dereferencing it
    in that case.
    
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Acked-by: Bob Copeland <me@bobcopeland.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.