Permalink
Commits on Oct 31, 2012
  1. fix merge conflict

    Oleksandr Natalenko committed Oct 31, 2012
Commits on Oct 28, 2012
  1. Linux 3.4.16

    gregkh committed Oct 28, 2012
  2. mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver

    commit bf7a01b upstream.
    
    The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It
    silently masks off at least one flag that might be set by the driver
    (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly
    others.
    
    Really, as long as driver writers exercise a small amount of care with
    NAND_* options, this mask is not necessary at all; it was only here to
    prevent certain options from accidentally being set by the driver. But the
    original thought turns out to be a bad idea occasionally. Thus, kill it.
    
    Note, this patch fixes some major gpmi-nand breakage.
    
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Tested-by: Huang Shijie <shijie8@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    computersforpeace committed with gregkh Jul 13, 2012
  3. sparc64: Be less verbose during vmemmap population.

    [ Upstream commit 2856cc2 ]
    
    On a 2-node machine with 256GB of ram we get 512 lines of
    console output, which is just too much.
    
    This mimicks Yinghai Lu's x86 commit c2b91e2
    (x86_64/mm: check and print vmemmap allocation continuous) except that
    we aren't ever going to get contiguous block pointers in between calls
    so just print when the virtual address or node changes.
    
    This decreases the output by an order of 16.
    
    Also demote this to KERN_DEBUG.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    davem330 committed with gregkh Aug 15, 2012
  4. sparc64: do not clobber personality flags in sys_sparc64_personality()

    [ Upstream commit a27032e ]
    
    There are multiple errors in how sys_sparc64_personality() handles
    personality flags stored in top three bytes.
    
    - directly comparing current->personality against PER_LINUX32 doesn't work
      in cases when any of the personality flags stored in the top three bytes
      are used.
    - directly forcefully setting personality to PER_LINUX32 or PER_LINUX
      discards any flags stored in the top three bytes
    
    Fix the first one by properly using personality() macro to compare only
    PER_MASK bytes.
    Fix the second one by setting only the bits that should be set, instead of
    overwriting the whole value.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Jiri Kosina committed with gregkh Aug 1, 2012
  5. sparc64: Fix bit twiddling in sparc_pmu_enable_event().

    [ Upstream commit e793d8c ]
    
    There was a serious disconnect in the logic happening in
    sparc_pmu_disable_event() vs. sparc_pmu_enable_event().
    
    Event disable is implemented by programming a NOP event into the PCR.
    
    However, event enable was not reversing this operation.  Instead, it
    was setting the User/Priv/Hypervisor trace enable bits.
    
    That's not sparc_pmu_enable_event()'s job, that's what
    sparc_pmu_enable() and sparc_pmu_disable() do .
    
    The intent of sparc_pmu_enable_event() is clear, since it first clear
    out the event type encoding field.  So fix this by OR'ing in the event
    encoding rather than the trace enable bits.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    davem330 committed with gregkh Oct 16, 2012
  6. sparc64: Like x86 we should check current->mm during perf backtrace g…

    …eneration.
    
    [ Upstream commit 08280e6 ]
    
    If the MM is not active, only report the top-level PC.  Do not try to
    access the address space.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    davem330 committed with gregkh Oct 15, 2012
  7. sparc64: fix ptrace interaction with force_successful_syscall_return()

    [ Upstream commit 55c2770 ]
    
    we want syscall_trace_leave() called on exit from any syscall;
    skipping its call in case we'd done force_successful_syscall_return()
    is broken...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Al Viro committed with gregkh Oct 11, 2012
  8. ipv6: addrconf: fix /proc/net/if_inet6

    [ Upstream commit 9f0d3c2 ]
    
    Commit 1d57830 (ipv6/addrconf: speedup /proc/net/if_inet6 filling)
    added bugs hiding some devices from if_inet6 and breaking applications.
    
    "ip -6 addr" could still display all IPv6 addresses, while "ifconfig -a"
    couldnt.
    
    One way to reproduce the bug is by starting in a shell :
    
    unshare -n /bin/bash
    ifconfig lo up
    
    And in original net namespace, lo device disappeared from if_inet6
    
    Reported-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
    Tested-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Mihai Maruseac <mihai.maruseac@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Eric Dumazet committed with gregkh Oct 16, 2012
  9. tcp: resets are misrouted

    [ Upstream commit 4c67525 ]
    
    After commit e2446ea ("tcp_v4_send_reset: binding oif to iif in no
    sock case").. tcp resets are always lost, when routing is asymmetric.
    Yes, backing out that patch will result in misrouting of resets for
    dead connections which used interface binding when were alive, but we
    actually cannot do anything here.  What's died that's died and correct
    handling normal unbound connections is obviously a priority.
    
    Comment to comment:
    > This has few benefits:
    >   1. tcp_v6_send_reset already did that.
    
    It was done to route resets for IPv6 link local addresses. It was a
    mistake to do so for global addresses. The patch fixes this as well.
    
    Actually, the problem appears to be even more serious than guaranteed
    loss of resets.  As reported by Sergey Soloviev <sol@eqv.ru>, those
    misrouted resets create a lot of arp traffic and huge amount of
    unresolved arp entires putting down to knees NAT firewalls which use
    asymmetric routing.
    
    Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alexey Kuznetsov committed with gregkh Oct 12, 2012
  10. RDS: fix rds-ping spinlock recursion

    [ Upstream commit 5175a5e ]
    
    This is the revised patch for fixing rds-ping spinlock recursion
    according to Venkat's suggestions.
    
    RDS ping/pong over TCP feature has been broken for years(2.6.39 to
    3.6.0) since we have to set TCP cork and call kernel_sendmsg() between
    ping/pong which both need to lock "struct sock *sk". However, this
    lock has already been hold before rds_tcp_data_ready() callback is
    triggerred. As a result, we always facing spinlock resursion which
    would resulting in system panic.
    
    Given that RDS ping is only used to test the connectivity and not for
    serious performance measurements, we can queue the pong transmit to
    rds_wq as a delayed response.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    CC: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
    CC: David S. Miller <davem@davemloft.net>
    CC: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Jie Liu <jeff.liu@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    pibroch committed with gregkh Oct 8, 2012
  11. vlan: don't deliver frames for unknown vlans to protocols

    [ Upstream commit 48cc32d ]
    
    6a32e4f made the vlan code skip marking
    vlan-tagged frames for not locally configured vlans as PACKET_OTHERHOST if
    there was an rx_handler, as the rx_handler could cause the frame to be received
    on a different (virtual) vlan-capable interface where that vlan might be
    configured.
    
    As rx_handlers do not necessarily return RX_HANDLER_ANOTHER, this could cause
    frames for unknown vlans to be delivered to the protocol stack as if they had
    been received untagged.
    
    For example, if an ipv6 router advertisement that's tagged for a locally not
    configured vlan is received on an interface with macvlan interfaces attached,
    macvlan's rx_handler returns RX_HANDLER_PASS after delivering the frame to the
    macvlan interfaces, which caused it to be passed to the protocol stack, leading
    to ipv6 addresses for the announced prefix being configured even though those
    are completely unusable on the underlying interface.
    
    The fix moves marking as PACKET_OTHERHOST after the rx_handler so the
    rx_handler, if there is one, sees the frame unchanged, but afterwards,
    before the frame is delivered to the protocol stack, it gets marked whether
    there is an rx_handler or not.
    
    Signed-off-by: Florian Zumbiehl <florz@florz.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Florian Zumbiehl committed with gregkh Oct 7, 2012
  12. skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard

    [ Upstream commit a2af139 ]
    
    Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive
    packets on a system with >4gb ram unless a 32bit DMA mask is used.
    
    This issue has been around for years and a fix was sent 3.5 years ago, but
    there was some debate as to whether it should instead be fixed as a PCI quirk.
    http://www.spinics.net/lists/netdev/msg88670.html
    
    However, 18 months later a similar workaround was introduced for another
    chipset exhibiting the same problem.
    http://www.spinics.net/lists/netdev/msg142287.html
    
    Signed-off-by: Graham Gower <graham.gower@gmail.com>
    Signed-off-by: Jan Ceuleers <jan.ceuleers@computer.org>
    Acked-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    grahamgower committed with gregkh Oct 8, 2012
  13. net: Fix skb_under_panic oops in neigh_resolve_output

    [ Upstream commit e1f1650 ]
    
    The retry loop in neigh_resolve_output() and neigh_connected_output()
    call dev_hard_header() with out reseting the skb to network_header.
    This causes the retry to fail with skb_under_panic. The fix is to
    reset the network_header within the retry loop.
    
    Signed-off-by: Ramesh Nagappa <ramesh.nagappa@ericsson.com>
    Reviewed-by: Shawn Lu <shawn.lu@ericsson.com>
    Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
    Reviewed-by: Billie Alsup <billie.alsup@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ramesh.nagappa@gmail.com committed with gregkh Oct 5, 2012
  14. infiniband: pass rdma_cm module to netlink_dump_start

    [ Upstream commit 809d5fc ]
    
    set netlink_dump_control.module to avoid panic.
    
    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Cc: Roland Dreier <roland@kernel.org>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Gao feng committed with gregkh Oct 4, 2012
  15. netlink: add reference of module in netlink_dump_start

    [ Upstream commit 6dc878a ]
    
    I get a panic when I use ss -a and rmmod inet_diag at the
    same time.
    
    It's because netlink_dump uses inet_diag_dump which belongs to module
    inet_diag.
    
    I search the codes and find many modules have the same problem.  We
    need to add a reference to the module which the cb->dump belongs to.
    
    Thanks for all help from Stephen,Jan,Eric,Steffen and Pablo.
    
    Change From v3:
    change netlink_dump_start to inline,suggestion from Pablo and
    Eric.
    
    Change From v2:
    delete netlink_dump_done,and call module_put in netlink_dump
    and netlink_sock_destruct.
    
    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Gao feng committed with gregkh Oct 4, 2012
  16. media: au0828: fix case where STREAMOFF being called on stopped strea…

    …m causes BUG()
    
    commit a595c1c upstream.
    
    We weren't checking whether the resource was in use before calling
    res_free(), so applications which called STREAMOFF on a v4l2 device that
    wasn't already streaming would cause a BUG() to be hit (MythTV).
    
    Reported-by: Larry Finger <larry.finger@lwfinger.net>
    Reported-by: Jay Harbeston <jharbestonus@gmail.com>
    Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    dheitmueller committed with gregkh Aug 7, 2012
  17. usb: dwc3: gadget: fix 'endpoint always busy' bug

    commit 041d81f upstream.
    
    If a USB transfer has already been started, meaning
    we have already issued StartTransfer command to that
    particular endpoint, DWC3_EP_BUSY flag has also
    already been set.
    
    When we try to cancel this transfer which is already
    in controller's cache, we will not receive XferComplete
    event and we must clear DWC3_EP_BUSY in order to allow
    subsequent requests to be properly started.
    
    The best place to clear that flag is right after issuing
    DWC3_DEPCMD_ENDTRANSFER.
    
    Reported-by: Moiz Sonasath <m-sonasath@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Felipe Balbi committed with gregkh Oct 4, 2012
  18. amd64_edac:__amd64_set_scrub_rate(): avoid overindexing scrubrates[]

    commit 168bfee upstream.
    
    If none of the elements in scrubrates[] matches, this loop will cause
    __amd64_set_scrub_rate() to incorrectly use the n+1th element.
    
    As the function is designed to use the final scrubrates[] element in the
    case of no match, we can fix this bug by simply terminating the array
    search at the n-1th element.
    
    Boris: this code is fragile anyway, see here why:
    http://marc.info/?l=linux-kernel&m=135102834131236&w=2
    
    It will be rewritten more robustly soonish.
    
    Reported-by: Denis Kirjanov <kirjanov@gmail.com>
    Cc: Doug Thompson <dougthompson@xmission.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Andrew Morton committed with gregkh Oct 23, 2012
  19. iommu/tegra: smmu: Fix deadly typo

    commit d0078e7 upstream.
    
    Fix a deadly typo in macro definition.
    
    Signed-off-by: Hiro Sugawara <hsugawara@nvidia.com>
    Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Hiro Sugawara committed with gregkh Oct 18, 2012
  20. pinctrl: tegra: set low power mode bank width to 2

    commit 154f3eb upstream.
    
    Signed-off-by: Pritesh Raithatha <praithatha@nvidia.com>
    Acked-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Pritesh Raithatha committed with gregkh Oct 17, 2012
  21. pinctrl: tegra: correct bank for pingroup and drv pingroup

    commit a03690e upstream.
    
    Signed-off-by: Pritesh Raithatha <praithatha@nvidia.com>
    Acked-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Pritesh Raithatha committed with gregkh Oct 17, 2012
  22. Revert "cgroup: Drop task_lock(parent) on cgroup_fork()"

    commit 9bb7130 upstream.
    
    This reverts commit 7e381b0.
    
    The commit incorrectly assumed that fork path always performed
    threadgroup_change_begin/end() and depended on that for
    synchronization against task exit and cgroup migration paths instead
    of explicitly grabbing task_lock().
    
    threadgroup_change is not locked when forking a new process (as
    opposed to a new thread in the same process) and even if it were it
    wouldn't be effective as different processes use different threadgroup
    locks.
    
    Revert the incorrect optimization.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    LKML-Reference: <20121008020000.GB2575@localhost>
    Acked-by: Li Zefan <lizefan@huawei.com>
    Bitterly-Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    htejun committed with gregkh Oct 19, 2012
  23. Revert "cgroup: Remove task_lock() from cgroup_post_fork()"

    commit d878383 upstream.
    
    This reverts commit 7e3aa30.
    
    The commit incorrectly assumed that fork path always performed
    threadgroup_change_begin/end() and depended on that for
    synchronization against task exit and cgroup migration paths instead
    of explicitly grabbing task_lock().
    
    threadgroup_change is not locked when forking a new process (as
    opposed to a new thread in the same process) and even if it were it
    wouldn't be effective as different processes use different threadgroup
    locks.
    
    Revert the incorrect optimization.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    LKML-Reference: <20121008020000.GB2575@localhost>
    Acked-by: Li Zefan <lizefan@huawei.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    htejun committed with gregkh Oct 19, 2012
  24. cgroup: notify_on_release may not be triggered in some cases

    commit 1f5320d upstream.
    
    notify_on_release must be triggered when the last process in a cgroup is
    move to another. But if the first(and only) process in a cgroup is moved to
    another, notify_on_release is not triggered.
    
    	# mkdir /cgroup/cpu/SRC
    	# mkdir /cgroup/cpu/DST
    	#
    	# echo 1 >/cgroup/cpu/SRC/notify_on_release
    	# echo 1 >/cgroup/cpu/DST/notify_on_release
    	#
    	# sleep 300 &
    	[1] 8629
    	#
    	# echo 8629 >/cgroup/cpu/SRC/tasks
    	# echo 8629 >/cgroup/cpu/DST/tasks
    	-> notify_on_release for /SRC must be triggered at this point,
    	   but it isn't.
    
    This is because put_css_set() is called before setting CGRP_RELEASABLE
    in cgroup_task_migrate(), and is a regression introduce by the
    commit:74a1166d(cgroups: make procs file writable), which was merged
    into v3.0.
    
    Acked-by: Li Zefan <lizefan@huawei.com>
    Cc: Ben Blum <bblum@andrew.cmu.edu>
    Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Daisuke Nishimura committed with gregkh Oct 4, 2012
  25. USB: option: add more ZTE devices

    commit 4b35f1c upstream.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    bmork committed with gregkh Oct 18, 2012
  26. USB: option: blacklist net interface on ZTE devices

    commit 1452df6 upstream.
    
    Based on information from the ZTE Windows drivers.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    bmork committed with gregkh Oct 18, 2012
  27. usb: host: xhci: New system added for Compliance Mode Patch on SN65LV…

    …PE502CP
    
    commit 4708097 upstream.
    
    This minor change adds a new system to which the "Fix Compliance Mode
    on SN65LVPE502CP Hardware" patch has to be applied also.
    
    System added:
    Vendor: Hewlett-Packard. System Model: Z1
    
    Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
    Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alexis R. Cortes committed with gregkh Oct 17, 2012
  28. usb: acm: fix the computation of the number of data bits

    commit 301a29d upstream.
    
    The current code assumes that CSIZE is 0000060, which appears to be
    wrong on some arches (such as powerpc).
    
    Signed-off-by: Nicolas Boullis <nboullis@debian.org>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    nboullis committed with gregkh Oct 15, 2012
  29. USB: cdc-acm: fix pipe type of write endpoint

    commit c521118 upstream.
    
    If the write endpoint is interrupt type, usb_sndintpipe() should
    be passed to usb_fill_int_urb() instead of usb_sndbulkpipe().
    
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Cc: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Ming Lei committed with gregkh Oct 16, 2012
  30. xen/x86: don't corrupt %eip when returning from a signal handler

    commit a349e23 upstream.
    
    In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
    (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
    /and/ the process has a pending signal then %eip (and %eax) are
    corrupted when returning to the main process after handling the
    signal.  The application may then crash with SIGSEGV or a SIGILL or it
    may have subtly incorrect behaviour (depending on what instruction it
    returned to).
    
    The occurs because handle_signal() is incorrectly thinking that there
    is a system call that needs to restarted so it adjusts %eip and %eax
    to re-execute the system call instruction (even though user space had
    not done a system call).
    
    If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
    (-516) then handle_signal() only corrupted %eax (by setting it to
    -EINTR).  This may cause the application to crash or have incorrect
    behaviour.
    
    handle_signal() assumes that regs->orig_ax >= 0 means a system call so
    any kernel entry point that is not for a system call must push a
    negative value for orig_ax.  For example, for physical interrupts on
    bare metal the inverse of the vector is pushed and page_fault() sets
    regs->orig_ax to -1, overwriting the hardware provided error code.
    
    xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
    instead of -1.
    
    Classic Xen kernels pushed %eax which works as %eax cannot be both
    non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
    other non-system call entry points and avoids some of the tests in
    handle_signal().
    
    There were similar bugs in xen_failsafe_callback() of both 32 and
    64-bit guests. If the fault was corrected and the normal return path
    was used then 0 was incorrectly pushed as the value for orig_ax.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Jan Beulich <JBeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    dvrabel committed with gregkh Oct 19, 2012
  31. x86: Exclude E820_RESERVED regions and memory holes above 4 GB from d…

    …irect mapping.
    
    commit 1bbbbe7 upstream.
    
    On systems with very large memory (1 TB in our case), BIOS may report a
    reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
    these from the direct mapping.
    
    [ hpa: this should be done not just for > 4 GB but for everything above the legacy
      region (1 MB), at the very least.  That, however, turns out to require significant
      restructuring.  That work is well underway, but is not suitable for rc/stable. ]
    
    Signed-off-by: Jacob Shin <jacob.shin@amd.com>
    Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Jacob Shin committed with gregkh Oct 20, 2011
  32. use clamp_t in UNAME26 fix

    commit 31fd84b upstream.
    
    The min/max call needed to have explicit types on some architectures
    (e.g. mn10300). Use clamp_t instead to avoid the warning:
    
      kernel/sys.c: In function 'override_release':
      kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    kees committed with gregkh Oct 20, 2012
  33. kernel/sys.c: fix stack memory content leak via UNAME26

    commit 2702b15 upstream.
    
    Calling uname() with the UNAME26 personality set allows a leak of kernel
    stack contents.  This fixes it by defensively calculating the length of
    copy_to_user() call, making the len argument unsigned, and initializing
    the stack buffer to zero (now technically unneeded, but hey, overkill).
    
    CVE-2012-0957
    
    Reported-by: PaX Team <pageexec@freemail.hu>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: PaX Team <pageexec@freemail.hu>
    Cc: Brad Spengler <spender@grsecurity.net>
    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@linuxfoundation.org>
    kees committed with gregkh Oct 19, 2012
  34. pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops

    commit fdc858a upstream.
    
    The sharpsl_pcmcia_ops structure gets passed into
    sa11xx_drv_pcmcia_probe, where it gets accessed at run-time,
    unlike all other pcmcia drivers that pass their structures
    into platform_device_add_data, which makes a copy.
    
    This means the gcc warning is valid and the structure
    must not be marked as __initdata.
    
    Without this patch, building collie_defconfig results in:
    
    drivers/pcmcia/pxa2xx_sharpsl.c:22:31: fatal error: mach-pxa/hardware.h: No such file or directory
    compilation terminated.
    make[3]: *** [drivers/pcmcia/pxa2xx_sharpsl.o] Error 1
    make[2]: *** [drivers/pcmcia] Error 2
    make[1]: *** [drivers] Error 2
    make: *** [sub-make] Error 2
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Pavel Machek <pavel@suse.cz>
    Cc: linux-pcmcia@lists.infradead.org
    Cc: Jochen Friedrich <jochen@scram.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    arndb committed with gregkh Apr 30, 2012