Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on May 8, 2009
  1. @gregkh

    Linux 2.6.29.3

    gregkh authored
  2. @gregkh

    ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

    Luis R. Rodriguez authored gregkh committed
    This is a port of commit
    91ed19f
    for 2.6.29.
    
    Without this after scanning your device will set
    the association ID to something bogus and what is
    being reported is multicast/broadcast frame are not
    being received. For details see this bug report:
    
    https://bugzilla.redhat.com/show_bug.cgi?id=498502
    
    >From the original commit:
    
    So that a new created IBSS network
    doesn't break on the first scan.
    
    It seems to Sujith and me that this
    stupid code unnecessary, too.
    
    So remove it...
    
    Reported-by: David Woodhouse <dwmw2@infradead.org>
    Tested-by: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Alina Friedrichsen <x-alina@gmx.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Jouni Malinen <Jouni.Malinen@atheros.com>
    Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    tracing: x86, mmiotrace: fix range test

    Stuart Bennett authored gregkh committed
    commit 33015c8 upstream.
    
    Matching on (addr == (p->addr + p->len)) causes problems when mappings
    are adjacent.
    
    [ Impact: fix mmiotrace confusion on adjacent iomaps ]
    
    Signed-off-by: Stuart Bennett <stuart@freedesktop.org>
    Acked-by: Pekka Paalanen <pq@iki.fi>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    LKML-Reference: <1240946271-7083-2-git-send-email-stuart@freedesktop.org>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    sched: account system time properly

    Eric Dumazet authored gregkh committed
    commit f5f293a upstream.
    
    Andrew Gallatin reported that IRQ and SOFTIRQ times were
    sometime not reported correctly on recent kernels, and even
    bisected to commit 457533a
    ([PATCH] fix scaled & unscaled cputime accounting) as the first
    bad commit.
    
    Further analysis pointed that commit
    79741dd ([PATCH] idle cputime
    accounting) was the real cause of the problem.
    
    account_process_tick() was not taking into account timer IRQ
    interrupting the idle task servicing a hard or soft irq.
    
    On mostly idle cpu, irqs were thus not accounted and top or
    mpstat could tell user/admin that cpu was 100 % idle, 0.00 %
    irq, 0.00 % softirq, while it was not.
    
    [ Impact: fix occasionally incorrect CPU statistics in top/mpstat ]
    
    Reported-by: Andrew Gallatin <gallatin@myri.com>
    Re-reported-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
    Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: rick.jones2@hp.com
    Cc: brice@myri.com
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    LKML-Reference: <49F84BC1.7080602@cosmosbay.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @jkivilin @gregkh

    rndis_wlan: fix initialization order for workqueue&workers

    jkivilin authored gregkh committed
    commit e805e4d upstream.
    
    rndis_wext_link_change() might be called from rndis_command() at
    initialization stage and priv->workqueue/priv->work have not been
    initialized yet. This causes invalid opcode at rndis_wext_bind on
    some brands of bcm4320.
    
    Fix by initializing workqueue/workers in rndis_wext_bind() before
    rndis_command is used.
    
    This bug has existed since 2.6.25, reported at:
    	http://bugzilla.kernel.org/show_bug.cgi?id=12794
    
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @kosaki @gregkh

    mm: fix Committed_AS underflow on large NR_CPUS environment

    kosaki authored gregkh committed
    commit 00a62ce upstream
    
    The Committed_AS field can underflow in certain situations:
    
    >         # while true; do cat /proc/meminfo  | grep _AS; sleep 1; done | uniq -c
    >               1 Committed_AS: 18446744073709323392 kB
    >              11 Committed_AS: 18446744073709455488 kB
    >               6 Committed_AS:    35136 kB
    >               5 Committed_AS: 18446744073709454400 kB
    >               7 Committed_AS:    35904 kB
    >               3 Committed_AS: 18446744073709453248 kB
    >               2 Committed_AS:    34752 kB
    >               9 Committed_AS: 18446744073709453248 kB
    >               8 Committed_AS:    34752 kB
    >               3 Committed_AS: 18446744073709320960 kB
    >               7 Committed_AS: 18446744073709454080 kB
    >               3 Committed_AS: 18446744073709320960 kB
    >               5 Committed_AS: 18446744073709454080 kB
    >               6 Committed_AS: 18446744073709320960 kB
    
    Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does
    not check for underflow.
    
    But NR_CPUS proportional isn't good calculation.  In general,
    possibility of lock contention is proportional to the number of online
    cpus, not theorical maximum cpus (NR_CPUS).
    
    The current kernel has generic percpu-counter stuff.  using it is right
    way.  it makes code simplify and percpu_counter_read_positive() don't
    make underflow issue.
    
    Reported-by: Dave Hansen <dave@linux.vnet.ibm.com>
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Eric B Munson <ebmunson@us.ibm.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Christoph Lameter <cl@linux-foundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gormanm @gregkh

    Ignore madvise(MADV_WILLNEED) for hugetlbfs-backed regions

    gormanm authored gregkh committed
    commit a425a63 upstream.
    
    madvise(MADV_WILLNEED) forces page cache readahead on a range of memory
    backed by a file.  The assumption is made that the page required is
    order-0 and "normal" page cache.
    
    On hugetlbfs, this assumption is not true and order-0 pages are
    allocated and inserted into the hugetlbfs page cache.  This leaks
    hugetlbfs page reservations and can cause BUGs to trigger related to
    corrupted page tables.
    
    This patch causes MADV_WILLNEED to be ignored for hugetlbfs-backed
    regions.
    
    Signed-off-by: Mel Gorman <mel@csn.ul.ie>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    clockevents: prevent endless loop in tick_handle_periodic()

    john stultz authored gregkh committed
    commit 74a03b6 upstream.
    
    tick_handle_periodic() can lock up hard when a one shot clock event
    device is used in combination with jiffies clocksource.
    
    Avoid an endless loop issue by requiring that a highres valid
    clocksource be installed before we call tick_periodic() in a loop when
    using ONESHOT mode. The result is we will only increment jiffies once
    per interrupt until a continuous hardware clocksource is available.
    
    Without this, we can run into a endless loop, where each cycle through
    the loop, jiffies is updated which increments time by tick_period or
    more (due to clock steering), which can cause the event programming to
    think the next event was before the newly incremented time and fail
    causing tick_periodic() to be called again and the whole process loops
    forever.
    
    [ Impact: prevent hard lock up ]
    
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @dwmw2 @gregkh

    intel-iommu: Avoid panic() for DRHD at address zero.

    dwmw2 authored gregkh committed
    (cherry picked from commit e523b38)
    
    If the BIOS does something obviously stupid, like claiming that the
    registers for the IOMMU are at physical address zero, then print a nasty
    message and abort, rather than trying to set up the IOMMU and then later
    panicking.
    
    It's becoming more and more obvious that trusting this stuff to the BIOS
    was a mistake.
    
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @dwmw2 @gregkh

    intel-iommu: Fix oops in device_to_iommu() when devices not found.

    dwmw2 authored gregkh committed
    (cherry picked from commit 4958c5d)
    
    It's possible for a device in the drhd->devices[] array to be NULL if
    it wasn't found at boot time, which means we have to check for that
    case.
    
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @dwmw2 @gregkh

    intel-iommu: Fix device-to-iommu mapping for PCI-PCI bridges.

    dwmw2 authored gregkh committed
    (cherry picked from commit 924b623)
    
    When the DMAR table identifies that a PCI-PCI bridge belongs to a given
    IOMMU, that means that the bridge and all devices behind it should be
    associated with the IOMMU. Not just the bridge itself.
    
    This fixes the device_to_iommu() function accordingly.
    
    (It's broken if you have the same PCI bus numbers in multiple domains,
    but this function was always broken in that way; I'll be dealing with
    that later).
    
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    cs5536: define dma_sff_read_status() method

    Sergei Shtylyov authored gregkh committed
    commit 15da90b upstream.
    
    The driver somehow got merged with the initializer for the dma_sff_read_status()
    method missing which caused kernel panic on bootup.
    
    This should fix the kernel.org bug #13026...
    
    Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
    Reported-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
    Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    proc: avoid information leaks to non-privileged processes

    Jake Edge authored gregkh committed
    commit f83ce3e upstream.
    
    By using the same test as is used for /proc/pid/maps and /proc/pid/smaps,
    only allow processes that can ptrace() a given process to see information
    that might be used to bypass address space layout randomization (ASLR).
    These include eip, esp, wchan, and start_stack in /proc/pid/stat as well
    as the non-symbolic output from /proc/pid/wchan.
    
    ASLR can be bypassed by sampling eip as shown by the proof-of-concept
    code at http://code.google.com/p/fuzzyaslr/ As part of a presentation
    (http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were
    also noted as possibly usable information leaks as well.  The
    start_stack address also leaks potentially useful information.
    
    Cc: Stable Team <stable@kernel.org>
    Signed-off-by: Jake Edge <jake@lwn.net>
    Acked-by: Arjan van de Ven <arjan@linux.intel.com>
    Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @bcopeland @gregkh

    ath5k: fix buffer overrun in rate debug code

    bcopeland authored gregkh committed
    commit b7fcb5c upstream.
    
    char bname[5] is too small for the string "X GHz" when the null
    terminator is taken into account.  Thus, turning on rate debugging
    can crash unless we have lucky stack alignment.
    
    Cc: stable@kernel.org
    Reported-by: Paride Legovini <legovini@spiro.fisica.unipd.it>
    Signed-off-by: Bob Copeland <me@bobcopeland.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @buytenh @gregkh

    mv643xx_eth: OOM handling fixes

    buytenh authored gregkh committed
    commit 1319eba upstream.
    
    Currently, when OOM occurs during rx ring refill, mv643xx_eth will get
    into an infinite loop, due to the refill function setting the OOM bit
    but not clearing the 'rx refill needed' bit for this queue, while the
    calling function (the NAPI poll handler) will call the refill function
    in a loop until the 'rx refill needed' bit goes off, without checking
    the OOM bit.
    
    This patch fixes this by checking the OOM bit in the NAPI poll handler
    before attempting to do rx refill.  This means that once OOM occurs,
    we won't try to do any memory allocations again until the next invocation
    of the poll handler.
    
    While we're at it, change the OOM flag to be a single bit instead of
    one bit per receive queue since OOM is a system state rather than a
    per-queue state, and cancel the OOM timer on entry to the NAPI poll
    handler if it's running to prevent it from firing when we've already
    come out of OOM.
    
    Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
    Cc: stable@kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @buytenh @gregkh

    mv643xx_eth: 64bit mib counter read fix

    buytenh authored gregkh committed
    commit 93af7ac upstream.
    
    On several mv643xx_eth hardware versions, the two 64bit mib counters
    for 'good octets received' and 'good octets sent' are actually 32bit
    counters, and reading from the upper half of the register has the same
    effect as reading from the lower half of the register: an atomic
    read-and-clear of the entire 32bit counter value.  This can under heavy
    traffic occasionally lead to small numbers being added to the upper
    half of the 64bit mib counter even though no 32bit wrap has occured.
    
    Since we poll the mib counters at least every 30 seconds anyway, we
    might as well just skip the reads of the upper halves of the hardware
    counters without breaking the stats, which this patch does.
    
    Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
    Cc: stable@kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @utrace @gregkh

    check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/

    utrace authored gregkh committed
    commit 437f7fd upstream.
    
    write_lock(&current->fs->lock) guarantees we can't wrongly miss
    LSM_UNSAFE_SHARE, this is what we care about. Use rcu_read_lock()
    instead of ->siglock to iterate over the sub-threads. We must see
    all CLONE_THREAD|CLONE_FS threads which didn't pass exit_fs(), it
    takes fs->lock too.
    
    With or without this patch we can miss the freshly cloned thread
    and set LSM_UNSAFE_SHARE, we don't care.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Roland McGrath <roland@redhat.com>
    [ Fixed lock/unlock typo  - Hugh ]
    Acked-by: Hugh Dickins <hugh@veritas.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @utrace @gregkh

    do_execve() must not clear fs->in_exec if it was set by another thread

    utrace authored gregkh committed
    commit 8c652f9 upstream.
    
    If do_execve() fails after check_unsafe_exec(), it clears fs->in_exec
    unconditionally. This is wrong if we race with our sub-thread which
    also does do_execve:
    
    	Two threads T1 and T2 and another process P, all share the same
    	->fs.
    
    	T1 starts do_execve(BAD_FILE). It calls check_unsafe_exec(), since
    	->fs is shared, we set LSM_UNSAFE but not ->in_exec.
    
    	P exits and decrements fs->users.
    
    	T2 starts do_execve(), calls check_unsafe_exec(), now ->fs is not
    	shared, we set fs->in_exec.
    
    	T1 continues, open_exec(BAD_FILE) fails, we clear ->in_exec and
    	return to the user-space.
    
    	T1 does clone(CLONE_FS /* without CLONE_THREAD */).
    
    	T2 continues without LSM_UNSAFE_SHARE while ->fs is shared with
    	another process.
    
    Change check_unsafe_exec() to return res = 1 if we set ->in_exec, and change
    do_execve() to clear ->in_exec depending on res.
    
    When do_execve() suceeds, it is safe to clear ->in_exec unconditionally.
    It can be set only if we don't share ->fs with another process, and since
    we already killed all sub-threads either ->in_exec == 0 or we are the
    only user of this ->fs.
    
    Also, we do not need fs->lock to clear fs->in_exec.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Roland McGrath <roland@redhat.com>
    Acked-by: Hugh Dickins <hugh@veritas.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    check_unsafe_exec() doesn't care about signal handlers sharing

    Al Viro authored gregkh committed
    commit f1191b5 upstream.
    
    ... since we'll unshare sighand anyway
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    New locking/refcounting for fs_struct

    Al Viro authored gregkh committed
    commit 498052b upstream.
    
    * all changes of current->fs are done under task_lock and write_lock of
      old fs->lock
    * refcount is not atomic anymore (same protection)
    * its decrements are done when removing reference from current; at the
      same time we decide whether to free it.
    * put_fs_struct() is gone
    * new field - ->in_exec.  Set by check_unsafe_exec() if we are trying to do
      execve() and only subthreads share fs_struct.  Cleared when finishing exec
      (success and failure alike).  Makes CLONE_FS fail with -EAGAIN if set.
    * check_unsafe_exec() may fail with -EAGAIN if another execve() from subthread
      is in progress.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    Take fs_struct handling to new file (fs/fs_struct.c)

    Al Viro authored gregkh committed
    commit 3e93cd6 upstream.
    
    Pure code move; two new helper functions for nfsd and daemonize
    (unshare_fs_struct() and daemonize_fs_struct() resp.; for now -
    the same code as used to be in callers).  unshare_fs_struct()
    exported (for nfsd, as copy_fs_struct()/exit_fs() used to be),
    copy_fs_struct() and exit_fs() don't need exports anymore.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    Get rid of bumping fs_struct refcount in pivot_root(2)

    Al Viro authored gregkh committed
    commit f8ef3ed upstream.
    
    Not because execve races with _that_ are serious - we really
    need a situation when final drop of fs_struct refcount is
    done by something that used to have it as current->fs.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    Kill unsharing fs_struct in __set_personality()

    Al Viro authored gregkh committed
    commit 11d06b2 upstream.
    
    That's a rudiment of altroot support.  I.e. it should've been buried
    a long time ago.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    Annotate struct fs_struct's usage count restriction

    David Howells authored gregkh committed
    commit 795e2fe upstream.
    
    Annotate struct fs_struct's usage count to indicate the restrictions upon it.
    It may not be incremented, except by clone(CLONE_FS), as this affects the
    check in check_unsafe_exec() in fs/exec.c.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    fix setuid sometimes wouldn't

    Hugh Dickins authored gregkh committed
    commit 7c2c7d9 upstream.
    
    check_unsafe_exec() also notes whether the fs_struct is being
    shared by more threads than will get killed by the exec, and if so
    sets LSM_UNSAFE_SHARE to make bprm_set_creds() careful about euid.
    But /proc/<pid>/cwd and /proc/<pid>/root lookups make transient
    use of get_fs_struct(), which also raises that sharing count.
    
    This might occasionally cause a setuid program not to change euid,
    in the same way as happened with files->count (check_unsafe_exec
    also looks at sighand->count, but /proc doesn't raise that one).
    
    We'd prefer exec not to unshare fs_struct: so fix this in procfs,
    replacing get_fs_struct() by get_fs_path(), which does path_get
    while still holding task_lock, instead of raising fs->count.
    
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    fix setuid sometimes doesn't

    Hugh Dickins authored gregkh committed
    commit e426b64 upstream.
    
    Joe Malicki reports that setuid sometimes doesn't: very rarely,
    a setuid root program does not get root euid; and, by the way,
    they have a health check running lsof every few minutes.
    
    Right, check_unsafe_exec() notes whether the files_struct is being
    shared by more threads than will get killed by the exec, and if so
    sets LSM_UNSAFE_SHARE to make bprm_set_creds() careful about euid.
    But /proc/<pid>/fd and /proc/<pid>/fdinfo lookups make transient
    use of get_files_struct(), which also raises that sharing count.
    
    There's a rather simple fix for this: exec's check on files->count
    has been redundant ever since 2.6.1 made it unshare_files() (except
    while compat_do_execve() omitted to do so) - just remove that check.
    
    [Note to -stable: this patch will not apply before 2.6.29: earlier
    releases should just remove the files->count line from unsafe_exec().]
    
    Reported-by: Joe Malicki <jmalicki@metacarta.com>
    Narrowed-down-by: Michael Itz <mitz@metacarta.com>
    Tested-by: Joe Malicki <jmalicki@metacarta.com>
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    compat_do_execve should unshare_files

    Hugh Dickins authored gregkh committed
    commit 53e9309 upstream.
    
    2.6.26's commit fd8328b
    "sanitize handling of shared descriptor tables in failing execve()"
    moved the unshare_files() from flush_old_exec() and several binfmts
    to the head of do_execve(); but forgot to make the same change to
    compat_do_execve(), leaving a CLONE_FILES files_struct shared across
    exec from a 32-bit process on a 64-bit kernel.
    
    It's arguable whether the files_struct really ought to be unshared
    across exec; but 2.6.1 made that so to stop the loading binary's fd
    leaking into other threads, and a 32-bit process on a 64-bit kernel
    ought to behave in the same way as 32 on 32 and 64 on 64.
    
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @gregkh

    powerpc: Sanitize stack pointer in signal handling code

    Josh Boyer authored gregkh committed
    This has been backported to 2.6.29.x from commit efbda86 in Linus' tree
    
    On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
    stack pointer passed into the kernel.  Most places handle this correctly, but
    the signal handling code uses the passed value directly for allocating signal
    stack frames.
    
    This fixes the issue by introducing a get_clean_sp function that returns a
    sanitized stack pointer.  For 32-bit tasks on a 64-bit kernel, the stack
    pointer is masked correctly.  In all other cases, the stack pointer is simply
    returned.
    
    Additionally, we pass an 'is_32' parameter to get_sigframe now in order to
    get the properly sanitized stack.  The callers are know to be 32 or 64-bit
    statically.
    
    Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @zhang-rui @gregkh

    ACPI: Revert conflicting workaround for BIOS w/ mangled PRT entries

    zhang-rui authored gregkh committed
    upstream 82babbb
    backported to 2.6.29.2
    
    2f894ef
    in Linux-2.6.21 worked around BIOS with mangled _PRT entries:
    http://bugzilla.kernel.org/show_bug.cgi?id=6859
    
    d0e184a
    worked around the same issue via ACPICA, and shipped in 2.6.27.
    
    Unfortunately the two workarounds conflict:
    http://bugzilla.kernel.org/show_bug.cgi?id=12270
    
    So revert the Linux specific one.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    USB: serial: fix lifetime and locking problems

    Alan Stern authored gregkh committed
    This is commit 2d93148 back-ported to
    2.6.29.
    
    This patch (as1229-3) fixes a few lifetime and locking problems in the
    usb-serial driver.  The main symptom is that an invalid kevent is
    created when the serial device is unplugged while a connection is
    active.
    
    	Ports should be unregistered when device is disconnected,
    	not when the parent usb_serial structure is deallocated.
    
    	Each open file should hold a reference to the corresponding
    	port structure, and the reference should be released when
    	the file is closed.
    
    	serial->disc_mutex should be acquired in serial_open(), to
    	resolve the classic race between open and disconnect.
    
    	serial_close() doesn't need to hold both serial->disc_mutex
    	and port->mutex at the same time.
    
    	Release the subdriver's module reference only after releasing
    	all the other references, in case one of the release routines
    	needs to invoke some code in the subdriver module.
    
    	Replace a call to flush_scheduled_work() (which is prone to
    	deadlocks) with cancel_work_sync().  Also, add a call to
    	cancel_work_sync() in the disconnect routine.
    
    	Reduce the scope of serial->disc_mutex in serial_disconnect().
    	The only place it really needs to protect is where the
    	"disconnected" flag is set.
    
    	Call the shutdown method from within serial_disconnect()
    	instead of destroy_serial(), because some subdrivers expect
    	the port data structures still to be in existence when
    	their shutdown method runs.
    
    This fixes the bug reported in
    
    	http://bugs.freedesktop.org/show_bug.cgi?id=20703
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
  31. @utrace @gregkh

    ptrace: ptrace_attach: fix the usage of ->cred_exec_mutex

    utrace authored gregkh committed
    commit cad81bc upstream.
    
    ptrace_attach() needs task->cred_exec_mutex, not current->cred_exec_mutex.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Roland McGrath <roland@redhat.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: James Morris <jmorris@namei.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @chombourger @gregkh

    kbuild: fix Module.markers permission error under cygwin

    chombourger authored gregkh committed
    commit 99e3a1e upstream.
    
    While building the kernel, we end-up calling modpost with -K and -M
    options for the same file (Modules.markers).  This is resulting in
    modpost's main function calling read_markers() and then write_markers() on
    the same file.
    
    We then have read_markers() mmap'ing the file, and writer_markers()
    opening that same file for writing.
    
    The issue is that read_markers() exits without munmap'ing the file and is
    as a matter holding a reference on Modules.markers.  When write_markers()
    is opening that very same file for writing, we still have a reference on
    it and cygwin (Windows?) is then making fopen() fail with EPERM.
    
    Calling release_file() before exiting read_markers() clears that reference
    (and memory leak) and fopen() then succeeds.
    
    Tested on both cygwin (1.3.22) and Linux.  Also ran modpost within
    valgrind on Linux to make sure that the munmap'ed file was not accessed
    after read_markers()
    
    Signed-off-by: Cedric Hombourger <chombourger@gmail.com>
    Cc: <stable@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @vtl @gregkh

    pagemap: require aligned-length, non-null reads of /proc/pid/pagemap

    vtl authored gregkh committed
    commit 0816178 upstream.
    
    The intention of commit aae8679
    ("pagemap: fix bug in add_to_pagemap, require aligned-length reads of
    /proc/pid/pagemap") was to force reads of /proc/pid/pagemap to be a
    multiple of 8 bytes, but now it allows to read 0 bytes, which actually
    puts some data to user's buffer.  According to POSIX, if count is zero,
    read() should return zero and has no other results.
    
    Signed-off-by: Vitaly Mayatskikh <v.mayatskih@gmail.com>
    Cc: Thomas Tuttle <ttuttle@google.com>
    Acked-by: Matt Mackall <mpm@selenic.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: <stable@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @gregkh

    drm/i915: allow tiled front buffers on 965+

    Jesse Barnes authored gregkh committed
    commit f544847 upstream.
    
    This patch corrects a pretty big oversight in the KMS code for 965+
    chips.  The current code is missing tiled surface register programming,
    so userland can allocate a tiled surface and use it for mode setting,
    resulting in corruption.  This patch fixes that, allowing for tiled
    front buffers on 965+.
    
    Cc: stable@kernel.org
    Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  35. @fujita @gregkh

    bio: fix memcpy corruption in bio_copy_user_iov()

    fujita authored gregkh committed
    commit 6983872 upstream.
    
    st driver uses blk_rq_map_user() in order to just build a request out
    of page frames. In this case, map_data->offset is a non zero value and
    iov[0].iov_base is NULL. We need to increase nr_pages for that.
    
    Cc: stable@kernel.org
    Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.