Documentation/filesystems/proc.txt       |    5 -
 Makefile                                 |    2
 arch/parisc/kernel/pci.c                 |    7 -
 arch/powerpc/include/asm/hw_irq.h        |   38 ----------
 arch/powerpc/kernel/asm-offsets.c        |    1
 arch/powerpc/kernel/entry_64.S           |    9 --
 arch/powerpc/kernel/irq.c                |    6 -
 arch/powerpc/kernel/time.c               |   60 +++++++++++++---
 arch/s390/kernel/ptrace.c                |    5 -
 arch/x86/include/asm/k8.h                |    5 +
 arch/x86/kernel/cpu/intel_cacheinfo.c    |    4 +
 arch/x86/kernel/process.c                |   12 +--
 crypto/authenc.c                         |   16 +++-
 debian/changelog                         |  110 +++++++++++++++++++++++++++++++
 drivers/acpi/sleep.c                     |   90 -------------------------
 drivers/hwmon/hp_accel.c                 |    2
 drivers/mmc/host/atmel-mci.c             |   14 ++-
 drivers/net/wireless/ath/ath9k/xmit.c    |    4 -
 drivers/net/wireless/iwlwifi/iwl-4965.c  |    5 +
 drivers/net/wireless/iwlwifi/iwl-5000.c  |    5 +
 drivers/net/wireless/p54/eeprom.c        |   31 +++++---
 drivers/scsi/megaraid/megaraid_sas.c     |   18 ++++-
 drivers/serial/imx.c                     |   10 ++
 drivers/video/bfin-t350mcqb-fb.c         |   15 ++--
 fs/btrfs/ioctl.c                         |    5 +
 fs/cachefiles/security.c                 |    4 +
 fs/cifs/cifsglob.h                       |    1
 fs/cifs/inode.c                          |   21 +++++
 fs/compat.c                              |    2
 fs/exec.c                                |    2
 fs/nilfs2/super.c                        |    1
 fs/notify/inotify/inotify_fsnotify.c     |    2
 fs/notify/inotify/inotify_user.c         |    9 +-
 fs/proc/array.c                          |   92 -------------------------
 fs/proc/task_mmu.c                       |   19 -----
 include/asm-generic/dma-mapping-common.h |    4 -
 include/linux/sched.h                    |    1
 kernel/fork.c                            |    2
 kernel/profile.c                         |    4 -
 mm/hugetlb.c                             |    2
 net/ipv4/udp.c                           |    6 -
 security/min_addr.c                      |    2
 sound/pci/hda/hda_intel.c                |    1
 sound/pci/hda/patch_conexant.c           |    7 +
 sound/pci/ice1712/maya44.c               |    6 -
 45 files changed, 322 insertions(+), 345 deletions(-)

New commits:
commit a9ce42ad7918b4ee955523db62ef2775628f0f48
Author: Stephen Hemminger <[email protected]>
Date:   Thu May 27 07:58:12 2010 -0700

    2.6.32-1+vyatta+25

commit 7b7a917a0d6160a15ba34b203874f98de90af192
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed May 26 14:29:57 2010 -0700

    Linux 2.6.32.14

commit 763f2ee657b24124d7a0b561b61bdb26231b0169
Author: Greg Kroah-Hartman <[email protected]>
Date:   Mon May 24 14:58:13 2010 -0700

    Revert "parisc: Set PCI CLS early in boot."

    This reverts the following patch, which shouldn't have been applied
    to the .32 stable tree as it causes problems.


      commit 5fd4514bb351b5ecb0da3692fff70741e5ed200c upstream.

      Set the PCI CLS early in the boot process to prevent
      device failures. In pcibios_set_master use the new
      pci_cache_line_size instead of a hard-coded value.

      Signed-off-by: Carlos O'Donell <[email protected]>
      Reviewed-by: Grant Grundler <[email protected]>
      Signed-off-by: Kyle McMartin <[email protected]>
      Signed-off-by: Greg Kroah-Hartman <[email protected]>


    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0ddd11675c96e939b25c36c69dd19eff58bd5967
Author: Herbert Xu <[email protected]>
Date:   Mon Apr 26 09:14:05 2010 +0800

    crypto: authenc - Add EINPROGRESS check

    commit 180ce7e81030e1ef763d58f97f9ab840ff57d848 upstream.

    When Steffen originally wrote the authenc async hash patch, he
    correctly had EINPROGRESS checks in place so that we did not invoke
    the original completion handler with it.

    Unfortuantely I told him to remove it before the patch was applied.

    As only MAY_BACKLOG request completion handlers are required to
    handle EINPROGRESS completions, those checks are really needed.

    This patch restores them.

    Reported-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4ee20bc28f74a77307091b15d498e44c7f54645e
Author: Luis R. Rodriguez <[email protected]>
Date:   Wed May 19 17:33:49 2010 -0400

    Revert "ath9k: fix lockdep warning when unloading module" on stable kernels

    Johannes' patch 34e8950 titled:

        mac80211: allow station add/remove to sleep

    changed the way mac80211 adds and removes peers. The new
    sta_add() / sta_remove() callbacks allowed the driver callbacks
    to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
    via the patch 4ca7786 titled:

        ath9k: convert to new station add/remove callbacks

    but this patch forgot to address a change in locking issue which
    Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
    build includes code for the 802.11 subsystem for 2.6.34 though so did
    already have the above two patches (ath9k_sta_remove() on his trace),
    the 2.6.33 kernel did not however have these two patches. Ming eventually
    cured his lockdep warnign via the patch a9f042c titled:

        ath9k: fix lockdep warning when unloading module

    This went in to 2.6.34 and although it was not marked as a stable
    fix it did get trickled down and applied on both 2.6.33 and 2.6.32.

    In review, the culprits:

        mac80211: allow station add/remove to sleep
    git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
    v2.6.34-rc1~233^2~49^2~107

        ath9k: convert to new station add/remove callbacks
    git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
    v2.6.34-rc1~233^2~49^2~10

        ath9k: fix lockdep warning when unloading module

    This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 
(invalid).

    git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
    v2.6.34-rc2~48^2~77^2~7
    git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
    v2.6.33.2~125
    git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
    v2.6.32.11~79

    The patch titled "ath9k: fix lockdep warning when unloading module"
    should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
    actually ended up causing the following warning:

    ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
    phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin cWmax23 txop=0
    phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin cWmax23 txop=0
    phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax txop”
    phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txopG
    phy0: device now idle
    ------------[ cut here ]------------
    WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
    Hardware name: 7660A14
    Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc>
    Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
    Call Trace:
     [<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0
     [<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20
     [<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0
     [<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20
     [<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
     [<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k]
     [<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211]
     [<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211]
     [<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
     [<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
     [<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211]
     [<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
     [<ffffffff81118540>] ? init_object+0x50/0x90
     [<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
     [<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
     [<ffffffff81514ca7>] notifier_call_chain+0x47/0x90
     [<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20
     [<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20
     [<ffffffff8144352d>] dev_close+0x4d/0xa0
     [<ffffffff814439a8>] rollback_registered+0x48/0x120
     [<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70
     [<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
     [<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
     [<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k]
     [<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k]
     [<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k]
     [<ffffffff8129d712>] pci_device_remove+0x32/0x60
     [<ffffffff81332373>] __device_release_driver+0x53/0xb0
     [<ffffffff81332498>] driver_detach+0xc8/0xd0
     [<ffffffff81331405>] bus_remove_driver+0x85/0xe0
     [<ffffffff81332a5a>] driver_unregister+0x5a/0x90
     [<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0
     [<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k]
     [<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k]
     [<ffffffff81092838>] sys_delete_module+0x1a8/0x270
     [<ffffffff8107ebe9>] ? up_read+0x9/0x10
     [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
    ---[ end trace fad957019ffdd40b ]---
    phy0: Removed STA 00:22:6b:56:fd:e8
    phy0: Destroyed STA 00:22:6b:56:fd:e8
    wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
    ath9k 0000:16:00.0: PCI INT A disabled

    The original lockdep fixed an issue where due to the new changes
    the driver was not disabling the bottom halves but it is incorrect
    to do this on the older kernels since IRQs are already disabled.

    Cc: Ming Lei <[email protected]>
    Cc: Johannes Berg <[email protected]>
    Cc: John W. Linville <[email protected]>
    Signed-off-by: Luis R. Rodriguez <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7823f8d63003bbb64f30d22929eae50742285b65
Author: Ryusuke Konishi <[email protected]>
Date:   Mon May 3 21:00:48 2010 +0900

    nilfs2: fix sync silent failure

    commit 973bec34bfc1bc2465646181653d67f767d418c8 upstream.

    As of 32a88aa1, __sync_filesystem() will return 0 if s_bdi is not set.
    And nilfs does not set s_bdi anywhere.  I noticed this problem by the
    warning introduced by the recent commit 5129a469 ("Catch filesystem
    lacking s_bdi").

     WARNING: at fs/super.c:959 vfs_kern_mount+0xc5/0x14e()
     Hardware name: PowerEdge 2850
     Modules linked in: nilfs2 loop tpm_tis tpm tpm_bios video shpchp 
pci_hotplug output dcdbas
     Pid: 3773, comm: mount.nilfs2 Not tainted 2.6.34-rc6-debug #38
     Call Trace:
      [<c1028422>] warn_slowpath_common+0x60/0x90
      [<c102845f>] warn_slowpath_null+0xd/0x10
      [<c1095936>] vfs_kern_mount+0xc5/0x14e
      [<c1095a03>] do_kern_mount+0x32/0xbd
      [<c10a811e>] do_mount+0x671/0x6d0
      [<c1073794>] ? __get_free_pages+0x1f/0x21
      [<c10a684f>] ? copy_mount_options+0x2b/0xe2
      [<c107b634>] ? strndup_user+0x48/0x67
      [<c10a81de>] sys_mount+0x61/0x8f
      [<c100280c>] sysenter_do_call+0x12/0x32

    This ensures to set s_bdi for nilfs and fixes the sync silent failure.

    Signed-off-by: Ryusuke Konishi <[email protected]>
    Acked-by: Jens Axboe <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 734c542a8aa9d7d49ffed09e671972851f25df5e
Author: Kees Cook <[email protected]>
Date:   Thu Apr 22 12:19:17 2010 -0700

    mmap_min_addr check CAP_SYS_RAWIO only for write

    commit 4ae69e6b718589abe97c9625ccbb1e0bc95a8c0e upstream.

    Redirecting directly to lsm, here's the patch discussed on lkml:
    http://lkml.org/lkml/2010/4/22/219

    The mmap_min_addr value is useful information for an admin to see without
    being root ("is my system vulnerable to kernel NULL pointer attacks?") and
    its setting is trivially easy for an attacker to determine by calling
    mmap() in PAGE_SIZE increments starting at 0, so trying to keep it private
    has no value.

    Only require CAP_SYS_RAWIO if changing the value, not reading it.

    Comment from Serge :

      Me, I like to write my passwords with light blue pen on dark blue
      paper, pasted on my window - if you're going to get my password, you're
      gonna get a headache.

    Signed-off-by: Kees Cook <[email protected]>
    Acked-by: Serge Hallyn <[email protected]>
    Signed-off-by: James Morris <[email protected]>
    (cherry picked from commit 822cceec7248013821d655545ea45d1c6a9d15b3)
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9e79d5307f9e53930b1cca4440e2691e0c4d0293
Author: Tomas Henzl <[email protected]>
Date:   Thu Feb 11 18:01:50 2010 +0100

    megaraid_sas: fix for 32bit apps

    commit b3dc1a212e5167984616445990c76056034f8eeb upstream.

    It looks like this patch -

    commit 7b2519afa1abd1b9f63aa1e90879307842422dae
    Author: Yang, Bo <[email protected]>
    Date:   Tue Oct 6 14:52:20 2009 -0600

        [SCSI] megaraid_sas: fix 64 bit sense pointer truncation

    has caused a problem for 32bit programs with 64bit os -

    http://bugzilla.kernel.org/show_bug.cgi?id001

    fix by converting the user space 32bit pointer to a 64 bit one when
    needed.

    [jejb: fix up some 64 bit warnings]
    Signed-off-by: Tomas Henzl <[email protected]>
    Cc: Bo Yang <[email protected]>
    Signed-off-by: James Bottomley <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 58e4a597dc9b8cd7ec28680a5b01c3f1718ca115
Author: David Howells <[email protected]>
Date:   Wed May 12 15:34:03 2010 +0100

    CacheFiles: Fix error handling in cachefiles_determine_cache_security()

    commit 7ac512aa8237c43331ffaf77a4fd8b8d684819ba upstream.

    cachefiles_determine_cache_security() is expected to return with a
    security override in place.  However, if set_create_files_as() fails, we
    fail to do this.  In this case, we should just reinstate the security
    override that was set by the caller.

    Furthermore, if set_create_files_as() fails, we should dispose of the
    new credentials we were in the process of creating.

    Signed-off-by: David Howells <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7bb08a1cac8ed8e4fda495bd907988bd4077b342
Author: Christian Lamparter <[email protected]>
Date:   Sat Oct 31 22:59:27 2009 +0100

    p54: disable channels with incomplete calibration data sets

    commit 93a59d7527147e3656664aa3179f8d19de256081 upstream.

    James Grossmann [1] reported that p54 spews out confusing
    messages instead of preventing the mayhem from happening.

    the reason is that "p54: generate channel list dynamically"
    is not perfect. It didn't discard incomplete channel data
    sets and therefore p54 advertised to support them as well.

    [1]: http://marc.info/?l=linux-wireless&m5699830215890

    Cc: Larry Finger <[email protected]>
    Reported-by: James Grossmann <[email protected]>
    Signed-off-by: Christian Lamparter <[email protected]>
    Signed-off-by: John W. Linville <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 79ec1d305fe1f2aa77797118fd31ea41e72e7867
Author: Wey-Yi Guy <[email protected]>
Date:   Tue Feb 9 08:14:11 2010 -0800

    iwlwifi: clear all the stop_queue flag after load firmware

    commit a9e10fb9b1c6ad16e73cf2656951fce3a817611e upstream.

    All the queues are awake and ready to use after loading firmware,
    for firmware reload case, if any queues was stopped before
    reload, mac80211 will wake those queues after restart hardware, so make
    sure all the flag used to keep track of the queue status are
    reset correctly.

    Signed-off-by: Wey-Yi Guy <[email protected]>
    Signed-off-by: Reinette Chatre <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 92d664daf9de677afcbf392fac48b734d752abff
Author: Robin Holt <[email protected]>
Date:   Tue May 11 14:06:46 2010 -0700

    revert "procfs: provide stack information for threads" and its fixup commits

    commit 34441427aab4bdb3069a4ffcda69a99357abcb2e upstream.

    Originally, commit d899bf7b ("procfs: provide stack information for
    threads") attempted to introduce a new feature for showing where the
    threadstack was located and how many pages are being utilized by the
    stack.

    Commit c44972f1 ("procfs: disable per-task stack usage on NOMMU") was
    applied to fix the NO_MMU case.

    Commit 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on
    64-bit") was applied to fix a bug in ia32 executables being loaded.

    Commit 9ebd4eba7 ("procfs: fix /proc/<pid>/stat stack pointer for kernel
    threads") was applied to fix a bug which had kernel threads printing a
    userland stack address.

    Commit 1306d603f ('proc: partially revert "procfs: provide stack
    information for threads"') was then applied to revert the stack pages
    being used to solve a significant performance regression.

    This patch nearly undoes the effect of all these patches.

    The reason for reverting these is it provides an unusable value in
    field 28.  For x86_64, a fork will result in the task->stack_start
    value being updated to the current user top of stack and not the stack
    start address.  This unpredictability of the stack_start value makes
    it worthless.  That includes the intended use of showing how much stack
    space a thread has.

    Other architectures will get different values.  As an example, ia64
    gets 0.  The do_fork() and copy_process() functions appear to treat the
    stack_start and stack_size parameters as architecture specific.

    I only partially reverted c44972f1 ("procfs: disable per-task stack usage
    on NOMMU") .  If I had completely reverted it, I would have had to change
    mm/Makefile only build pagewalk.o when CONFIG_PROC_PAGE_MONITOR is
    configured.  Since I could not test the builds without significant effort,
    I decided to not change mm/Makefile.

    I only partially reverted 89240ba0 ("x86, fs: Fix x86 procfs stack
    information for threads on 64-bit") .  I left the KSTK_ESP() change in
    place as that seemed worthwhile.

    Signed-off-by: Robin Holt <[email protected]>
    Cc: Stefani Seibold <[email protected]>
    Cc: KOSAKI Motohiro <[email protected]>
    Cc: Michal Simek <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c8c4c2f04ba486355d7bc6d909a0723acd10f91d
Author: KOSAKI Motohiro <[email protected]>
Date:   Fri Jan 8 14:42:56 2010 -0800

    proc: partially revert "procfs: provide stack information for threads"

    commit 1306d603fcf1f6682f8575d1ff23631a24184b21 upstream.

    Commit d899bf7b (procfs: provide stack information for threads) introduced
    to show stack information in /proc/{pid}/status.  But it cause large
    performance regression.  Unfortunately /proc/{pid}/status is used ps
    command too and ps is one of most important component.  Because both to
    take mmap_sem and page table walk are heavily operation.

    If many process run, the ps performance is,

    [before d899bf7b]

    % perf stat ps >/dev/null

     Performance counter stats for 'ps':

         4090.435806  task-clock-msecs         #      0.032 CPUs
                 229  context-switches         #      0.000 M/sec
                   0  CPU-migrations           #      0.000 M/sec
                 234  page-faults              #      0.000 M/sec
          8587565207  cycles                   #   2099.425 M/sec
          9866662403  instructions             #      1.149 IPC
          3789415411  cache-references         #    926.409 M/sec
            30419509  cache-misses             #      7.437 M/sec

       128.859521955  seconds time elapsed

    [after d899bf7b]

    % perf stat  ps  > /dev/null

     Performance counter stats for 'ps':

         4305.081146  task-clock-msecs         #      0.028 CPUs
                 480  context-switches         #      0.000 M/sec
                   2  CPU-migrations           #      0.000 M/sec
                 237  page-faults              #      0.000 M/sec
          9021211334  cycles                   #   2095.480 M/sec
         10605887536  instructions             #      1.176 IPC
          3612650999  cache-references         #    839.160 M/sec
            23917502  cache-misses             #      5.556 M/sec

       152.277819582  seconds time elapsed

    Thus, this patch revert it. Fortunately /proc/{pid}/task/{tid}/smaps
    provide almost same information. we can use it.

    Commit d899bf7b introduced two features:

     1) Add the annotattion of [thread stack: xxxx] mark to
        /proc/{pid}/task/{tid}/maps.
     2) Add StackUsage field to /proc/{pid}/status.

    I only revert (2), because I haven't seen (1) cause regression.

    Signed-off-by: KOSAKI Motohiro <[email protected]>
    Cc: Stefani Seibold <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Alexey Dobriyan <[email protected]>
    Cc: "Eric W. Biederman" <[email protected]>
    Cc: Randy Dunlap <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Cc: Andi Kleen <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2df4055341695af413219a6160e2f60f22779a8c
Author: Vitaliy Kulikov <[email protected]>
Date:   Mon Mar 15 09:01:26 2010 +0100

    ALSA: hda - New Intel HDA controller

    commit c602c8ad45d6ee6ad91fc544513cc96f70790983 upstream.

    Added a PCI controller id on new Dell laptops.

    Signed-off-by: Vitaliy Kulikov <[email protected]>
    Cc: AmenophisIII <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cca8198578b62538e5d30efd94fd7b50a062dfb1
Author: Dan Rosenberg <[email protected]>
Date:   Sat May 15 11:27:37 2010 -0400

    Btrfs: check for read permission on src file in the clone ioctl

    commit 5dc6416414fb3ec6e2825fd4d20c8bf1d7fe0395 upstream.

    The existing code would have allowed you to clone a file that was
    only open for writing

    Signed-off-by: Chris Mason <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f46c7299a930469f51e30b7be281c33630917244
Author: Andreas Herrmann <[email protected]>
Date:   Tue Apr 27 12:13:48 2010 +0200

    x86, amd: Check X86_FEATURE_OSVW bit before accessing OSVW MSRs

    commit f01487119dda3d9f58c9729c7361ecc50a61c188 upstream.

    If host CPU is exposed to a guest the OSVW MSRs are not guaranteed
    to be present and a GP fault occurs. Thus checking the feature flag is
    essential.

    Signed-off-by: Andreas Herrmann <[email protected]>
    LKML-Reference: <[email protected]>
    Signed-off-by: H. Peter Anvin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 798e99d358157dfcec37c1b0b911ed711d0e0da6
Author: Frank Arnold <[email protected]>
Date:   Thu Apr 22 16:06:59 2010 +0200

    x86, cacheinfo: Turn off L3 cache index disable feature in virtualized 
environments

    commit 7f284d3cc96e02468a42e045f77af11e5ff8b095 upstream.

    When running a quest kernel on xen we get:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
    IP: [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x2ca/0x3df
    PGD 0
    Oops: 0000 [#1] SMP
    last sysfs file:
    CPU 0
    Modules linked in:

    Pid: 0, comm: swapper Tainted: G        W  2.6.34-rc3 #1 /HVM domU
    RIP: 0010:[<ffffffff8142f2fb>]  [<ffffffff8142f2fb>] 
cpuid4_cache_lookup_regs+0x
    2ca/0x3df
    RSP: 0018:ffff880002203e08  EFLAGS: 00010046
    RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000060
    RDX: 0000000000000000 RSI: 0000000000000040 RDI: 0000000000000000
    RBP: ffff880002203ed8 R08: 00000000000017c0 R09: ffff880002203e38
    R10: ffff8800023d5d40 R11: ffffffff81a01e28 R12: ffff880187e6f5c0
    R13: ffff880002203e34 R14: ffff880002203e58 R15: ffff880002203e68
    FS:  0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000038 CR3: 0000000001a3c000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a44020)
    Stack:
     ffffffff810d7ecb ffff880002203e20 ffffffff81059140 ffff880002203e30
    <0> ffffffff810d7ec9 0000000002203e40 000000000050d140 ffff880002203e70
    <0> 0000000002008140 0000000000000086 ffff880040020140 ffffffff81068b8b
    Call Trace:
     <IRQ>
     [<ffffffff810d7ecb>] ? sync_supers_timer_fn+0x0/0x1c
     [<ffffffff81059140>] ? mod_timer+0x23/0x25
     [<ffffffff810d7ec9>] ? arm_supers_timer+0x34/0x36
     [<ffffffff81068b8b>] ? hrtimer_get_next_event+0xa7/0xc3
     [<ffffffff81058e85>] ? get_next_timer_interrupt+0x19a/0x20d
     [<ffffffff8142fa23>] get_cpu_leaves+0x5c/0x232
     [<ffffffff8106a7b1>] ? sched_clock_local+0x1c/0x82
     [<ffffffff8106a9a0>] ? sched_clock_tick+0x75/0x7a
     [<ffffffff8107748c>] generic_smp_call_function_single_interrupt+0xae/0xd0
     [<ffffffff8101f6ef>] smp_call_function_single_interrupt+0x18/0x27
     [<ffffffff8100a773>] call_function_single_interrupt+0x13/0x20
     <EOI>
     [<ffffffff8143c468>] ? notifier_call_chain+0x14/0x63
     [<ffffffff810295c6>] ? native_safe_halt+0xc/0xd
     [<ffffffff810114eb>] ? default_idle+0x36/0x53
     [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
     [<ffffffff81423a9a>] rest_init+0x7e/0x80
     [<ffffffff81b10dd2>] start_kernel+0x40e/0x419
     [<ffffffff81b102c8>] x86_64_start_reservations+0xb3/0xb7
     [<ffffffff81b103c4>] x86_64_start_kernel+0xf8/0x107
    Code: 14 d5 40 ff ae 81 8b 14 02 31 c0 3b 15 47 1c 8b 00 7d 0e 48 8b 05 36 
1c 8b
     00 48 63 d2 48 8b 04 d0 c7 85 5c ff ff ff 00 00 00 00 <8b> 70 38 48 8d 8d 
5c ff
     ff ff 48 8b 78 10 ba c4 01 00 00 e8 eb
    RIP  [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x2ca/0x3df
     RSP <ffff880002203e08>
    CR2: 0000000000000038
    ---[ end trace a7919e7f17c0a726 ]---

    The L3 cache index disable feature of AMD CPUs has to be disabled if the
    kernel is running as guest on top of a hypervisor because northbridge
    devices are not available to the guest. Currently, this fixes a boot
    crash on top of Xen. In the future this will become an issue on KVM as
    well.

    Check if northbridge devices are present and do not enable the feature
    if there are none.

    [ hpa: backported to 2.6.34 ]

    Signed-off-by: Frank Arnold <[email protected]>
    LKML-Reference: <[email protected]>
    Acked-by: Borislav Petkov <[email protected]>
    Signed-off-by: H. Peter Anvin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b53d27ff66e343520df4d287c419235fbe6e3fea
Author: Borislav Petkov <[email protected]>
Date:   Sat Apr 24 09:56:53 2010 +0200

    x86, k8: Fix build error when K8_NB is disabled

    commit ade029e2aaacc8965a548b0b0f80c5bee97ffc68 upstream.

    K8_NB depends on PCI and when the last is disabled (allnoconfig) we fail
    at the final linking stage due to missing exported num_k8_northbridges.
    Add a header stub for that.

    Signed-off-by: Borislav Petkov <[email protected]>
    LKML-Reference: <20100503183036.gj26...@aftab>
    Signed-off-by: H. Peter Anvin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7ff4b9ccdac041b6745b9c43ac2cc5639ffc8c1b
Author: Hugh Dickins <[email protected]>
Date:   Fri May 14 19:44:10 2010 -0700

    profile: fix stats and data leakage

    commit 16a2164bb03612efe79a76c73da6da44445b9287 upstream.

    If the kernel is large or the profiling step small, /proc/profile
    leaks data and readprofile shows silly stats, until readprofile -r
    has reset the buffer: clear the prof_buffer when it is vmalloc()ed.

    Signed-off-by: Hugh Dickins <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d8ca15afb835aff91c0a1dedb1b4e47171180312
Author: Pavel Emelyanov <[email protected]>
Date:   Wed May 12 15:34:07 2010 -0700

    inotify: don't leak user struct on inotify release

    commit b3b38d842fa367d862b83e7670af4e0fd6a80fc0 upstream.

    inotify_new_group() receives a get_uid-ed user_struct and saves the
    reference on group->inotify_data.user.  The problem is that free_uid() is
    never called on it.

    Issue seem to be introduced by 63c882a0 (inotify: reimplement inotify
    using fsnotify) after 2.6.30.

    Signed-off-by: Pavel Emelyanov <[email protected]>
    Eric Paris <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Eric Paris <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c606e701ef469582a991aabd3a6f7816a9a9d351
Author: Eric Paris <[email protected]>
Date:   Tue May 11 17:17:40 2010 -0400

    inotify: race use after free/double free in inotify inode marks

    commit e08733446e72b983fed850fc5d8bd21b386feb29 upstream.

    There is a race in the inotify add/rm watch code.  A task can find and
    remove a mark which doesn't have all of it's references.  This can
    result in a use after free/double free situation.

    Task A                                      Task B
    ------------                                -----------
    inotify_new_watch()
     allocate a mark (refcnt == 1)
     add it to the idr
                                        inotify_rm_watch()
                                         inotify_remove_from_idr()
                                          fsnotify_put_mark()
                                              refcnt hits 0, free
     take reference because we are on idr
     [at this point it is a use after free]
     [time goes on]
     refcnt may hit 0 again, double free

    The fix is to take the reference BEFORE the object can be found in the
    idr.

    Signed-off-by: Eric Paris <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bbd7e6ac76997aadf0b827aaca61ba767eb5dd78
Author: Daniel T Chen <[email protected]>
Date:   Mon May 10 21:50:04 2010 +0200

    ALSA: hda: Fix 0 dB for Lenovo models using Conexant CX20549 (Venice)

    commit 0ebf9e3692d640917fb792a7494d05e1f5b1058f upstream.

    Reference: 
http://mailman.alsa-project.org/pipermail/alsa-devel/2010-May/027525.html

    As reported on the mailing list, we also need to cap to the 0 dB offset
    for Lenovo models, else the sound will be distorted.

    Reported-and-Tested-by: Tim Starling <[email protected]>
    Signed-off-by: Daniel T Chen <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2a3097f24a0e4224e89f4e7e1ed75ef372d11068
Author: Takashi Iwai <[email protected]>
Date:   Wed May 12 16:43:32 2010 +0200

    ALSA: ice1724 - Fix ESI Maya44 capture source control

    commit 8213466596bf10b75887754773ee13c10cf86f5c upstream.

    The capture source control of maya44 was wrongly coded with the bit
    shift instead of the bit mask.  Also, the slot for line-in was
    wrongly assigned (slot 5 instead of 4).

    Reported-by: Alex Chernyshoff <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5eb1c77df310f6def7a8d9e9e2e2061142a2ad63
Author: Valentin Longchamp <[email protected]>
Date:   Wed May 5 11:47:07 2010 +0200

    serial: imx.c: fix CTS trigger level lower to avoid lost chars

    commit 1c5250d6163dac28be3afabdfb6c723f107051b7 upstream.

    The imx CTS trigger level is left at its reset value that is 32
    chars. Since the RX FIFO has 32 entries, when CTS is raised, the
    FIFO already is full. However, some serial port devices first empty
    their TX FIFO before stopping when CTS is raised, resulting in lost
    chars.

    This patch sets the trigger level lower so that other chars arrive
    after CTS is raised, there is still room for 16 of them.

    Signed-off-by: Valentin Longchamp<[email protected]>
    Tested-by: Philippe Rétornaz<[email protected]>
    Acked-by: Wolfram Sang<[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cfbca0d1ae392a3b4fb490094ddb951d96591ef3
Author: Jeff Layton <[email protected]>
Date:   Tue May 11 14:59:55 2010 -0400

    cifs: guard against hardlinking directories

    commit 3d69438031b00c601c991ab447cafb7d5c3c59a6 upstream.

    When we made serverino the default, we trusted that the field sent by the
    server in the "uniqueid" field was actually unique. It turns out that it
    isn't reliably so.

    Samba, in particular, will just put the st_ino in the uniqueid field when
    unix extensions are enabled. When a share spans multiple filesystems, it's
    quite possible that there will be collisions. This is a server bug, but
    when the inodes in question are a directory (as is often the case) and
    there is a collision with the root inode of the mount, the result is a
    kernel panic on umount.

    Fix this by checking explicitly for directory inodes with the same
    uniqueid. If that is the case, then we can assume that using server inode
    numbers will be a problem and that they should be disabled.

    Fixes Samba bugzilla 7407

    Signed-off-by: Jeff Layton <[email protected]>
    Reviewed-and-Tested-by: Suresh Jayaraman <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 73ef533de7533fcf514403125a0d4747d3390317
Author: Paul Mackerras <[email protected]>
Date:   Tue Apr 13 20:46:04 2010 +0000

    powerpc/perf_event: Fix oops due to perf_event_do_pending call

    commit 0fe1ac48bef018bed896307cd12f6ca9b5e704ab upstream.

    Anton Blanchard found that large POWER systems would occasionally
    crash in the exception exit path when profiling with perf_events.
    The symptom was that an interrupt would occur late in the exit path
    when the MSR[RI] (recoverable interrupt) bit was clear.  Interrupts
    should be hard-disabled at this point but they were enabled.  Because
    the interrupt was not recoverable the system panicked.

    The reason is that the exception exit path was calling
    perf_event_do_pending after hard-disabling interrupts, and
    perf_event_do_pending will re-enable interrupts.

    The simplest and cleanest fix for this is to use the same mechanism
    that 32-bit powerpc does, namely to cause a self-IPI by setting the
    decrementer to 1.  This means we can remove the tests in the exception
    exit path and raw_local_irq_restore.

    This also makes sure that the call to perf_event_do_pending from
    timer_interrupt() happens within irq_enter/irq_exit.  (Note that
    calling perf_event_do_pending from timer_interrupt does not mean that
    there is a possible 1/HZ latency; setting the decrementer to 1 ensures
    that the timer interrupt will happen immediately, i.e. within one
    timebase tick, which is a few nanoseconds or 10s of nanoseconds.)

    Signed-off-by: Paul Mackerras <[email protected]>
    Signed-off-by: Benjamin Herrenschmidt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fa157eec79e78a875790df6faf53b3501c33a462
Author: Gerald Schaefer <[email protected]>
Date:   Wed May 12 09:32:12 2010 +0200

    ptrace: fix return value of do_syscall_trace_enter()

    commit 545c174d1f093a462b4bb9131b23d5ea72a600e1 upstream.

    strace may change the system call number, so regs->gprs[2] must not
    be read before tracehook_report_syscall_entry(). This fixes a bug
    where "strace -f" will hang after a vfork().

    Signed-off-by: Gerald Schaefer <[email protected]>
    Signed-off-by: Martin Schwidefsky <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ee7a0b92fcc8d1ab43cff3dd75baeb2f646a93ff
Author: Nicolas Ferre <[email protected]>
Date:   Tue May 11 14:06:50 2010 -0700

    mmc: atmel-mci: remove data error interrupt after xfer

    commit abc2c9fdf636c4335a8d72ac3c5ae152bca44b68 upstream.

    Disable data error interrupts while we are actually recording that there
    is not such errors.  This will prevent, in some cases, the warning message
    printed at new request queuing (in atmci_start_request()).

    Signed-off-by: Nicolas Ferre <[email protected]>
    Cc: Haavard Skinnemoen <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit eac2ef18972dbc56c2540c7302a6c7a1437352ef
Author: Nicolas Ferre <[email protected]>
Date:   Tue May 11 14:06:49 2010 -0700

    mmc: atmel-mci: prevent kernel oops while removing card

    commit 009a891b22395fc86e5f34057d79fffee4509ab5 upstream.

    The removing of an SD card in certain circumstances can lead to a kernel
    oops if we do not make sure that the "data" field of the host structure is
    valid.  This patch adds a test in atmci_dma_cleanup() function and also
    calls atmci_stop_dma() before throwing away the reference to data.

    Signed-off-by: Nicolas Ferre <[email protected]>
    Cc: Haavard Skinnemoen <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 85e346fae9b44a4acfe4d63afae62eae4c25e586
Author: Nicolas Ferre <[email protected]>
Date:   Tue May 11 14:06:48 2010 -0700

    mmc: atmel-mci: fix two parameters swapped

    commit ebb1fea9b3adf25d7e2f643c614163af4f93a17f upstream.

    Two parameters were swapped in the calls to atmci_init_slot().

    Signed-off-by: Nicolas Ferre <[email protected]>
    Reported-by: Anders Grahn <[email protected]>
    Cc: Haavard Skinnemoen <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e053045d37ac1f3d62be0e9cc81f54d5b9980c9e
Author: Alex Chiang <[email protected]>
Date:   Tue May 11 10:21:38 2010 -0600

    ACPI: sleep: eliminate duplicate entries in acpisleep_dmi_table[]

    commit 7d6fb7bd1919517937ec390f6ca2d7bcf4f89fb6 upstream.

    Duplicate entries ended up acpisleep_dmi_table[] by accident.
    They don't hurt functionality, but they are ugly, so let's get
    rid of them.

    Signed-off-by: Alex Chiang <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c7c781e8307febc10ce5f25adad79d8d4f65104e
Author: FUJITA Tomonori <[email protected]>
Date:   Tue May 11 14:06:43 2010 -0700

    dma-mapping: fix dma_sync_single_range_*

    commit f33d7e2d2d113a63772bbc993cdec3b5327f0ef1 upstream.

    dma_sync_single_range_for_cpu() and dma_sync_single_range_for_device() use
    a wrong address with a partial synchronization.

    Signed-off-by: FUJITA Tomonori <[email protected]>
    Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 38f2212686db52d61ed5d86fd6c69ae5f65d6449
Author: Mel Gorman <[email protected]>
Date:   Tue May 11 14:06:53 2010 -0700

    hugetlbfs: kill applications that use MAP_NORESERVE with SIGBUS instead of 
OOM-killer

    commit 4a6018f7f4f1075c1a5403b5ec0ee7262187b86c upstream.

    Ordinarily, application using hugetlbfs will create mappings with
    reserves.  For shared mappings, these pages are reserved before mmap()
    returns success and for private mappings, the caller process is guaranteed
    and a child process that cannot get the pages gets killed with sigbus.

    An application that uses MAP_NORESERVE gets no reservations and mmap()
    will always succeed at the risk the page will not be available at fault
    time.  This might be used for example on very large sparse mappings where
    the developer is confident the necessary huge pages exist to satisfy all
    faults even though the whole mapping cannot be backed by huge pages.
    Unfortunately, if an allocation does fail, VM_FAULT_OOM is returned to the
    fault handler which proceeds to trigger the OOM-killer.  This is
    unhelpful.

    Even without hugetlbfs mounted, a user using mmap() can trivially trigger
    the OOM-killer because VM_FAULT_OOM is returned (will provide example
    program if desired - it's a whopping 24 lines long).  It could be
    considered a DOS available to an unprivileged user.

    This patch alters hugetlbfs to kill a process that uses MAP_NORESERVE
    where huge pages were not available with SIGBUS instead of triggering the
    OOM killer.

    This change affects hugetlb_cow() as well.  I feel there is a failure case
    in there, but I didn't create one.  It would need a fairly specific target
    in terms of the faulting application and the hugepage pool size.  The
    hugetlb_no_page() path is much easier to hit but both might as well be
    closed.

    Signed-off-by: Mel Gorman <[email protected]>
    Cc: Lee Schermerhorn <[email protected]>
    Cc: David Rientjes <[email protected]>
    Cc: Andi Kleen <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ec9dd41fc73ca85b0afb21ce4bbf563afeb08d6d
Author: Michael Hennerich <[email protected]>
Date:   Tue May 11 14:07:00 2010 -0700

    fbdev: bfin-t350mcqb-fb: fix fbmem allocation with blanking lines

    commit de145b44b95b9d3212a82d1c0f29b09778ef33c5 upstream.

    The current allocation does not include the memory required for blanking
    lines.  So avoid memory corruption when multiple devices are using the DMA
    memory near each other.

    Signed-off-by: Michael Hennerich <[email protected]>
    Signed-off-by: Mike Frysinger <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7b7be5f379bd001c86372c2e042cb7779c4f0a06
Author: Oliver Neukum <[email protected]>
Date:   Tue May 11 14:07:03 2010 -0700

    hp_accel: fix race in device removal

    commit 06efbeb4a47b6f865e1c9d175ab9d6e90b69ae9e upstream.

    The work queue has to be flushed after the device has been made
    inaccessible.  The patch closes a window during which a work queue might
    remain active after the device is removed and would then lead to ACPI
    calls with undefined behavior.

    Signed-off-by: Oliver Neukum <[email protected]>
    Acked-by: Eric Piel <[email protected]>
    Acked-by: Pavel Machek <[email protected]>
    Cc: Pavel Herrmann <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5f4213d39b4965791875f6e10f6f7268ba8dfc2c
Author: Bjørn Mork <[email protected]>
Date:   Thu May 6 03:44:34 2010 +0000

    ipv4: udp: fix short packet and bad checksum logging

    commit ccc2d97cb7c798e785c9f198de243e2b59f7073b upstream.

    commit 2783ef23 moved the initialisation of saddr and daddr after
    pskb_may_pull() to avoid a potential data corruption.  Unfortunately
    also placing it after the short packet and bad checksum error paths,
    where these variables are used for logging.  The result is bogus
    output like

    [92238.389505] UDP: short packet: From 2.0.0.0:65535 23715/178 to 
0.0.0.0:65535

    Moving the saddr and daddr initialisation above the error paths, while still
    keeping it after the pskb_may_pull() to keep the fix from commit 2783ef23.

    Signed-off-by: Bjørn Mork <[email protected]>
    Acked-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h©ce42ad7918b4ee955523db62ef2775628f0f48
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h{7a917a0d6160a15ba34b203874f98de90af192
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hv3f2ee657b24124d7a0b561b61bdb26231b0169
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h
dd11675c96e939b25c36c69dd19eff58bd5967
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hNe20bc28f74a77307091b15d498e44c7f54645e
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hx23f8d63003bbb64f30d22929eae50742285b65
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hs4c542a8aa9d7d49ffed09e671972851f25df5e
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hž79d5307f9e53930b1cca4440e2691e0c4d0293
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hXe4a597dc9b8cd7ec28680a5b01c3f1718ca115
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h{b08a1cac8ed8e4fda495bd907988bd4077b342
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hyec1d305fe1f2aa77797118fd31ea41e72e7867
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h’d664daf9de677afcbf392fac48b734d752abff
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÈc4c2f04ba486355d7bc6d909a0723acd10f91d
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h-f4055341695af413219a6160e2f60f22779a8c
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÌa8198578b62538e5d30efd94fd7b50a062dfb1
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hô6c7299a930469f51e30b7be281c33630917244
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hy8e99d358157dfcec37c1b0b911ed711d0e0da6
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hµ3d27ff66e343520df4d287c419235fbe6e3fea
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hf4b9ccdac041b6745b9c43ac2cc5639ffc8c1b
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hØca15afb835aff91c0a1dedb1b4e47171180312
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÆ06e701ef469582a991aabd3a6f7816a9a9d351
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h»d7e6ac76997aadf0b827aaca61ba767eb5dd78
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h*3097f24a0e4224e89f4e7e1ed75ef372d11068
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h^b1c77df310f6def7a8d9e9e2e2061142a2ad63
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÏbca0d1ae392a3b4fb490094ddb951d96591ef3
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hsef533de7533fcf514403125a0d4747d3390317
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hú157eec79e78a875790df6faf53b3501c33a462
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hî7a0b92fcc8d1ab43cff3dd75baeb2f646a93ff
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hêc2ef18972dbc56c2540c7302a6c7a1437352ef
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h…e346fae9b44a4acfe4d63afae62eae4c25e586
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hà53045d37ac1f3d62be0e9cc81f54d5b9980c9e
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hÇc781e8307febc10ce5f25adad79d8d4f65104e
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h8f2212686db52d61ed5d86fd6c69ae5f65d6449
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hì9dd41fc73ca85b0afb21ce4bbf563afeb08d6d
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h{7be5f379bd001c86372c2e042cb7779c4f0a06
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h_4213d39b4965791875f6e10f6f7268ba8dfc2c
_______________________________________________
svn mailing list
[email protected]
http://mailman.vyatta.com/mailman/listinfo/svn

Reply via email to