Permalink
Commits on Aug 1, 2011
  1. release 2.6.35.14

    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Andi Kleen committed Aug 1, 2011
  2. IGMP snooping: set mrouters_only flag for IPv6 traffic

    [ upstream commit fc2af6c ]
     properly
    
    Upon reception of a MGM report packet the kernel sets the mrouters_only flag
    in a skb that is a clone of the original skb, which means that the bridge
    loses track of MGM packets (cb buffers are tied to a specific skb and not
    shared) and it ends up forwading join requests to the bridge interface.
    
    This can cause unexpected membership timeouts and intermitent/permanent loss
    of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
    
        A snooping switch should forward IGMP Membership Reports only to
        those ports where multicast routers are attached.
        [...]
        Sending membership reports to other hosts can result, for IGMPv1
        and IGMPv2, in unintentionally preventing a host from joining a
        specific multicast group.
    
    Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Signed-off-by: David S. Miller <davem@conan.davemloft.net>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Fernando Luis Vázquez Cao committed with Andi Kleen Jun 13, 2011
  3. IGMP snooping: set mrouters_only flag for IPv4 traffic

    [ upstream commit 62b2bcb ]
     properly
    
    Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
    mrouters_only flag in a skb that may be a clone of the original skb, which
    means that sometimes the bridge loses track of membership report packets (cb
    buffers are tied to a specific skb and not shared) and it ends up forwading
    join requests to the bridge interface.
    
    This can cause unexpected membership timeouts and intermitent/permanent loss
    of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
    
        A snooping switch should forward IGMP Membership Reports only to
        those ports where multicast routers are attached.
        [...]
        Sending membership reports to other hosts can result, for IGMPv1
        and IGMPv2, in unintentionally preventing a host from joining a
        specific multicast group.
    
    Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Tested-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
    Signed-off-by: David S. Miller <davem@conan.davemloft.net>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Fernando Luis Vázquez Cao committed with Andi Kleen Jun 13, 2011
  4. ipv6: add special mode forwarding=2 to send RS while

    [ upstream commit c3bccac ]
     configured as router
    
    Similar to accepting router advertisement, the IPv6 stack does not send router
    solicitations if forwarding is enabled.
    
    This patch enables this behavior to be overruled by setting forwarding to the
    special value 2.
    
    Signed-off-by: Thomas Graf <tgraf@infradead.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Thomas Graf committed with Andi Kleen Sep 3, 2010
  5. x86, mtrr: lock stop machine during MTRR rendezvous sequence

    [ upstream commit 6d3321e ]
    
    MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
    happen in parallel with another system wide rendezvous using
    stop_machine(). This can lead to deadlock (The order in which
    works are queued can be different on different cpu's. Some cpu's
    will be running the first rendezvous handler and others will be running
    the second rendezvous handler. Each set waiting for the other set to join
    for the system wide rendezvous, leading to a deadlock).
    
    MTRR rendezvous sequence is not implemented using stop_machine() as this
    gets called both from the process context aswell as the cpu online paths
    (where the cpu has not come online and the interrupts are disabled etc).
    stop_machine() works with only online cpus.
    
    For now, take the stop_machine mutex in the MTRR rendezvous sequence that
    gets called from an online cpu (here we are in the process context
    and can potentially sleep while taking the mutex). And the MTRR rendezvous
    that gets triggered during cpu online doesn't need to take this stop_machine
    lock (as the stop_machine() already ensures that there is no cpu hotplug
    going on in parallel by doing get_online_cpus())
    
        TBD: Pursue a cleaner solution of extending the stop_machine()
             infrastructure to handle the case where the calling cpu is
             still not online and use this for MTRR rendezvous sequence.
    
    fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008
    
    Reported-by: Vadim Kotelnikov <vadimuzzz@inbox.ru>
    Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
    Cc: stable@kernel.org # 2.6.35+, backport a week or two after this gets more testing in mainline
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Suresh Siddha committed with Andi Kleen Jun 23, 2011
  6. SERIAL: SC26xx: Fix link error.

    [ upstream commit f2eb3cd ]
    
    Kconfig allows enabling console support for the SC26xx driver even when
    it's configured as a module resulting in a:
    
    ERROR: "uart_console_device" [drivers/tty/serial/sc26xx.ko] undefined!
    
    modpost error since the driver was merged in
    eea63e0 [SC26XX: New serial driver for
    SC2681 uarts] in 2.6.25.  Fixed by only allowing console support to be
    enabled if the driver is builtin.
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-serial@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Cc: stable <stable@kernel.org>
    Acked-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    ralfbaechle committed with Andi Kleen Jun 27, 2011
  7. ASoC: Ensure we delay long enough for WM8994 FLL to lock

    [ upstream commit 8e9ddf8 ]
     when starting
    
    This delay is very conservative.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Cc: stable@kernel.org
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    broonie committed with Andi Kleen Jul 2, 2011
  8. ARM: 6989/1: perf: do not start the PMU when no events are

    [ upstream commit f4f3843 ]
     present
    
    armpmu_enable can be called in situations where no events are present
    (for example, from the event rotation tick after a profiled task has
    exited). In this case, we currently start the PMU anyway which may
    leave it active inevitably without any events being monitored.
    
    This patch adds a simple check to the enabling code so that we avoid
    starting the PMU when no events are present.
    
    Cc: <stable@kernel.org>
    Reported-by: Ashwin Chaugle <ashwinc@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    wildea01 committed with Andi Kleen Jul 1, 2011
  9. Staging: hv: netvsc: Fix a bug in accounting transmit slots

    [ upstream commit 9079ce6 ]
    
    The transmit slots were manipulated without proper locking. Fix this bug by
    making the variable tracking the transmit slots atomic.
    
    This patch should be ported to prior stable kernels 2.6.32 and later.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    kattisrinivasan committed with Andi Kleen Jun 16, 2011
  10. staging: comedi: fix infoleak to userspace

    [ upstream commit 819cbb1 ]
    
    driver_name and board_name are pointers to strings, not buffers of size
    COMEDI_NAMELEN.  Copying COMEDI_NAMELEN bytes of a string containing
    less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes.
    
    Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Vasiliy Kulikov committed with Andi Kleen Jun 26, 2011
  11. staging: r8192e_pci: Handle duplicate PCI ID 0x10ec:0x8192

    [ upstream commit 1c50bf7 ]
     conflict with rtl8192se
    
    There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and
    RTL8192SE. The method of distinguishing them is by the revision ID
    at offset 0x8 of the PCI configuration space. If the value is 0x10,
    then the device uses rtl8192se for a driver.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    lwfinger committed with Andi Kleen Jun 19, 2011
  12. iommu/amd: Don't use MSI address range for DMA addresses

    [ upstream commit 17f5b56 ]
    
    Reserve the MSI address range in the address allocator so
    that MSI addresses are not handed out as dma handles.
    
    Cc: stable@kernel.org
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Joerg Roedel committed with Andi Kleen Jul 6, 2011
  13. ARM: pxa: fix PGSR register address calculation

    [ upstream commit beb0c9b ]
    
    The file mfp-pxa2xx.c defines a macro, PGSR(), which translates a gpio
    bank number to a PGSR register address. The function pxa2xx_mfp_suspend()
    erroneously passed in a gpio number instead of a gpio bank number.
    
    Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
    Cc: stable@kernel.org
    Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Paul Parsons committed with Andi Kleen May 8, 2011
  14. tracing: Have "enable" file use refcounts like the "filter"

    [ upstream commit 40ee4df ]
     file
    
    The "enable" file for the event system can be removed when a module
    is unloaded and the event system only has events from that module.
    As the event system nr_events count goes to zero, it may be freed
    if its ref_count is also set to zero.
    
    Like the "filter" file, the "enable" file may be opened by a task and
    referenced later, after a module has been unloaded and the events for
    that event system have been removed.
    
    Although the "filter" file referenced the event system structure,
    the "enable" file only references a pointer to the event system
    name. Since the name is freed when the event system is removed,
    it is possible that an access to the "enable" file may reference
    a freed pointer.
    
    Update the "enable" file to use the subsystem_open() routine that
    the "filter" file uses, to keep a reference to the event system
    structure while the "enable" file is opened.
    
    Cc: <stable@kernel.org>
    Reported-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Steven Rostedt committed with Andi Kleen Jul 5, 2011
  15. tracing: Fix bug when reading system filters on module

    [ upstream commit e9dbfae ]
     removal
    
    The event system is freed when its nr_events is set to zero. This happens
    when a module created an event system and then later the module is
    removed. Modules may share systems, so the system is allocated when
    it is created and freed when the modules are unloaded and all the
    events under the system are removed (nr_events set to zero).
    
    The problem arises when a task opened the "filter" file for the
    system. If the module is unloaded and it removed the last event for
    that system, the system structure is freed. If the task that opened
    the filter file accesses the "filter" file after the system has
    been freed, the system will access an invalid pointer.
    
    By adding a ref_count, and using it to keep track of what
    is using the event system, we can free it after all users
    are finished with the event system.
    
    Cc: <stable@kernel.org>
    Reported-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Steven Rostedt committed with Andi Kleen Jul 5, 2011
  16. ASoC: ak4642: fixup snd_soc_update_bits mask for PW_MGMT2

    [ upstream commit bd7fdbc ]
    
    mask didn't cover update-data
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Cc: stable@kernel.org
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    morimoto committed with Andi Kleen Jul 7, 2011
  17. mac80211: fix TKIP replay vulnerability

    [ upstream commit 3445951 ]
    
    Unlike CCMP, the presence or absence of the QoS
    field doesn't change the encryption, only the
    TID is used. When no QoS field is present, zero
    is used as the TID value. This means that it is
    possible for an attacker to take a QoS packet
    with TID 0 and replay it as a non-QoS packet.
    
    Unfortunately, mac80211 uses different IVs for
    checking the validity of the packet's TKIP IV
    when it checks TID 0 and when it checks non-QoS
    packets. This means it is vulnerable to this
    replay attack.
    
    To fix this, use the same replay counter for
    TID 0 and non-QoS packets by overriding the
    rx->queue value to 0 if it is 16 (non-QoS).
    
    This is a minimal fix for now. I caused this
    issue in
    
    commit 1411f9b
    Author: Johannes Berg <johannes@sipsolutions.net>
    Date:   Thu Jul 10 10:11:02 2008 +0200
    
        mac80211: fix RX sequence number check
    
    while fixing a sequence number issue (there,
    a separate counter needs to be used).
    
    [AK: This was a non trivial backport. Johannes, John,
    please double check]
    
    Cc: stable@kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    jmberg committed with Andi Kleen Jul 7, 2011
  18. v4l2-ioctl.c: prefill tuner type for g_frequency and

    [ upstream commit 227690d ]
     g/s_tuner
    
    The subdevs are supposed to receive a valid tuner type for the g_frequency
    and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill
    this in v4l2-ioctl.c based on whether the device node from which this is
    called is a radio node or not.
    
    The spec does not require applications to fill in the type, and if they
    leave it at 0 then the 'check_mode' call in tuner-core.c will return
    an error and the ioctl does nothing.
    
    Cc: stable@kernel.org
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Hans Verkuil committed with Andi Kleen Jun 12, 2011
  19. pvrusb2: fix g/s_tuner support

    [ upstream commit 50e9efd ]
    
    The tuner-core subdev requires that the type field of v4l2_tuner is
    filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
    use that yet, so we have to do it manually based on whether the current
    input is radio or not.
    
    Tested with my pvrusb2.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Acked-by: Mike Isely <isely@pobox.com>
    Cc: stable@kernel.org
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Hans Verkuil committed with Andi Kleen Jun 12, 2011
  20. bttv: fix s_tuner for radio

    [ upstream commit a024c1a ]
    
    Fix typo: g_tuner should have been s_tuner.
    
    Tested with a bttv card.
    
    Cc: stable@kernel.org
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Hans Verkuil committed with Andi Kleen Jun 12, 2011
  21. SUNRPC: Fix a race between work-queue and rpc_killall_tasks

    [ upstream commit b55c598 ]
    
    Since rpc_killall_tasks may modify the rpc_task's tk_action field
    without any locking, we need to be careful when dereferencing it.
    
    Reported-by: Ben Greear <greearb@candelatech.com>
    Tested-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: stable@kernel.org
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Trond Myklebust committed with Andi Kleen Jul 6, 2011
  22. usb: musb: restore INDEX register in resume path

    [ upstream commit 3c5fec7 ]
    
    Restoring the missing INDEX register value in musb_restore_context().
    Without this suspend resume functionality is broken with offmode
    enabled.
    
    Cc: stable@kernel.org
    Acked-by: Anand Gadiyar <gadiyar@ti.com>
    Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Ajay Kumar Gupta committed with Andi Kleen Jul 8, 2011
  23. mac80211: Restart STA timers only on associated state

    [ upstream commit 676b58c ]
    
    A panic was observed when the device is failed to resume properly,
    and there are no running interfaces. ieee80211_reconfig tries
    to restart STA timers on unassociated state.
    
    Cc: stable@kernel.org
    Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Rajkumar Manoharan committed with Andi Kleen Jul 7, 2011
  24. EHCI: only power off port if over-current is active

    [ upstream commit 81463c1 ]
    
    MAX4967 USB power supply chip we use on our boards signals over-current when
    power is not enabled; once it's enabled, over-current signal returns to normal.
    That unfortunately caused the endless stream of "over-current change on port"
    messages. The EHCI root hub code reacts on every over-current signal change
    with powering off the port -- such change event is generated the moment the
    port power is enabled, so once enabled the power is immediately cut off.
    I think we should only cut off power when we're seeing the active over-current
    signal, so I'm adding such check to that code. I also think that the fact that
    we've cut off the port power should be reflected in the result of GetPortStatus
    request immediately, hence I'm adding a PORTSCn register readback after write...
    
    Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
    Cc: stable@kernel.org
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Sergei Shtylyov committed with Andi Kleen Jul 6, 2011
  25. mm/nommu.c: fix remap_pfn_range()

    [ upstream commit 8f3b132 ]
    
    remap_pfn_range() means map physical address pfn<<PAGE_SHIFT to user addr.
    
    For nommu arch it's implemented by vma->vm_start = pfn << PAGE_SHIFT which
    is wrong acroding the original meaning of this function.  And some driver
    developer using remap_pfn_range() with correct parameter will get
    unexpected result because vm_start is changed.  It should be implementd
    like addr = pfn << PAGE_SHIFT but which is meanless on nommu arch, this
    patch just make it simply return.
    
    Parameter name and setting of vma->vm_flags also be fixed.
    
    Signed-off-by: Bob Liu <lliubbo@gmail.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: David Howells <dhowells@redhat.com>
    Acked-by: Greg Ungerer <gerg@uclinux.org>
    Cc: Mike Frysinger <vapier@gentoo.org>
    Cc: Bob Liu <lliubbo@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: Andi Kleen <ak@linux.intel.com>
    lliubbo committed with Andi Kleen Jul 8, 2011
  26. firewire: ohci: do not bind to Pinnacle cards, avert panic

    [ upstream commit 7f7e371 ]
    
    When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a
    "Register access failure" is logged and an interrupt storm or a kernel
    panic happens.  https://bugzilla.kernel.org/show_bug.cgi?id=36622
    
    Until this is sorted out (if that is going to succeed at all), let's
    just prevent firewire-ohci from touching these devices.
    
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Cc: <stable@kernel.org>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Stefan Richter committed with Andi Kleen Jul 9, 2011
  27. ARM: pxa/cm-x300: fix V3020 RTC functionality

    [ upstream commit 6c7b3ea ]
    
    While in sleep mode the CS# and other V3020 RTC GPIOs must be driven
    high, otherwise V3020 RTC fails to keep the right time in sleep mode.
    
    Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
    Cc: stable@kernel.org
    Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    igor-grinberg committed with Andi Kleen May 9, 2011
  28. SUNRPC: Fix use of static variable in rpcb_getport_async

    [ upstream commit ec0dd26 ]
    
    Because struct rpcbind_args *map was declared static, if two
    threads entered this method at the same time, the values
    assigned to map could be sent two two differen tasks.
    This could cause all sorts of problems, include use-after-free
    and double-free of memory.
    
    Fix this by removing the static declaration so that the map
    pointer is on the stack.
    
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Cc: stable@kernel.org
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    greearb committed with Andi Kleen Jul 12, 2011
  29. x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS

    [ upstream commit abe48b1 ]
    
    Since 2.6.36 (23016bf), Linux prints the existence of "epb" in /proc/cpuinfo,
    Since 2.6.38 (d5532ee), the x86_energy_perf_policy(8) utility has
    been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS.
    
    However, the typical BIOS fails to initialize the MSR, presumably
    because this is handled by high-volume shrink-wrap operating systems...
    
    Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8).
    As a result, WSM-EP, SNB, and later hardware from Intel will run in its
    default hardware power-on state (performance), which assumes that users
    care for performance at all costs and not for energy efficiency.
    While that is fine for performance benchmarks, the hardware's intended default
    operating point is "normal" mode...
    
    Initialize the MSR to the "normal" by default during kernel boot.
    
    x86_energy_perf_policy(8) is available to change the default after boot,
    should the user have a different preference.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980
    Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: <stable@kernel.org>
    lenb committed with Andi Kleen Jul 14, 2011
  30. x86: Look for IA32_ENERGY_PERF_BIAS support

    [ upstream commit 23016bf ]
    
    The new IA32_ENERGY_PERF_BIAS MSR allows system software to give
    hardware a hint whether OS policy favors more power saving,
    or more performance.  This allows the OS to have some influence
    on internal hardware power/performance tradeoffs where the OS
    has previously had no influence.
    
    The support for this feature is indicated by CPUID.06H.ECX.bit3,
    as documented in the Intel Architectures Software Developer's Manual.
    
    This patch discovers support of this feature and displays it
    as "epb" in /proc/cpuinfo.
    
    Signed-off-by: Venkatesh Pallipadi <venki@google.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    LKML-Reference: <alpine.LFD.2.00.1006032310160.6669@localhost.localdomain>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Venkatesh Pallipadi committed with Andi Kleen Jun 4, 2010
  31. svcrpc: fix list-corrupting race on nfsd shutdown

    [ upstream commit ebc63e5 ]
    
    After commit 3262c81 "[PATCH] knfsd:
    split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no
    longer removed its xpt_ready (then sk_ready) field from whatever list it
    was on, noting that there was no point since the whole list was about to
    be destroyed anyway.
    
    That was mostly true, but forgot that a few svc_xprt_enqueue()'s might
    still be hanging around playing with the about-to-be-destroyed list, and
    could get themselves into trouble writing to freed memory if we left
    this xprt on the list after freeing it.
    
    (This is actually functionally identical to a patch made first by Ben
    Greear, but with more comments.)
    
    Cc: stable@kernel.org
    Cc: gnb@fmeh.org
    Reported-by: Ben Greear <greearb@candelatech.com>
    Tested-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    J. Bruce Fields committed with Andi Kleen Jun 29, 2011
  32. firewire: cdev: return -ENOTTY for unimplemented ioctls, not

    [ upstream commit d873d79 ]
     -EINVAL
    
    On Jun 27 Linus Torvalds wrote:
    > The correct error code for "I don't understand this ioctl" is ENOTTY.
    > The naming may be odd, but you should think of that error value as a
    > "unrecognized ioctl number, you're feeding me random numbers that I
    > don't understand and I assume for historical reasons that you tried to
    > do some tty operation on me".
    [...]
    > The EINVAL thing goes way back, and is a disaster. It predates Linux
    > itself, as far as I can tell. You'll find lots of man-pages that have
    > this line in it:
    >
    >   EINVAL Request or argp is not valid.
    >
    > and it shows up in POSIX etc. And sadly, it generally shows up
    > _before_ the line that says
    >
    >   ENOTTY The specified request does not apply to the kind of object
    > that the descriptor d references.
    >
    > so a lot of people get to the EINVAL, and never even notice the ENOTTY.
    [...]
    > At least glibc (and hopefully other C libraries) use a _string_ that
    > makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for
    > device"
    
    So let's correct this in the <linux/firewire-cdev.h> ABI while it is
    still young, relative to distributor adoption.
    
    Side note:  We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch,
    but also on _IOC_SIZE mismatch.  An ioctl with an unsupported size of
    argument structure can be seen as an unsupported version of that ioctl.
    
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Cc: <stable@kernel.org>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Stefan Richter committed with Andi Kleen Jul 9, 2011
  33. firewire: cdev: prevent race between first get_info ioctl

    [ upstream commit 93b3790 ]
     and bus reset event queuing
    
    Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO
    ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events
    to be read(2) by the client.  The get_info ioctl is practically always
    issued right away after open, hence this condition only occurs if the
    client opens during a bus reset, especially during a rapid series of bus
    resets.
    
    The problem with this condition is twofold:
    
      - These bus reset events carry the (as yet undocumented) @closure
        value of 0.  But it is not the kernel's place to choose closures;
        they are privat to the client.  E.g., this 0 value forced from the
        kernel makes it unsafe for clients to dereference it as a pointer to
        a closure object without NULL pointer check.
    
      - It is impossible for clients to determine the relative order of bus
        reset events from get_info ioctl(2) versus those from read(2),
        except in one way:  By comparison of closure values.  Again, such a
        procedure imposes complexity on clients and reduces freedom in use
        of the bus reset closure.
    
    So, change the ABI to suppress queuing of bus reset events before the
    first FW_CDEV_IOC_GET_INFO ioctl was issued by the client.
    
    Note, this ABI change cannot be version-controlled.  The kernel cannot
    distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO
    ioctl.
    
    We will try to back-merge this change into currently maintained stable/
    longterm series, and we only document the new behaviour.  The old
    behavior is now considered a kernel bug, which it basically is.
    
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Cc: <stable@kernel.org>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Stefan Richter committed with Andi Kleen Jul 9, 2011
  34. USB: OHCI: fix another regression for NVIDIA controllers

    [ upstream commit 6ea12a0 ]
    
    The NVIDIA series of OHCI controllers continues to be troublesome.  A
    few people using the MCP67 chipset have reported that even with the
    most recent kernels, the OHCI controller fails to handle new
    connections and spams the system log with "unable to enumerate USB
    port" messages.  This is different from the other problems previously
    reported for NVIDIA OHCI controllers, although it is probably related.
    
    It turns out that the MCP67 controller does not like to be kept in the
    RESET state very long.  After only a few seconds, it decides not to
    work any more.  This patch (as1479) changes the PCI initialization
    quirk code so that NVIDIA controllers are switched into the SUSPEND
    state after 50 ms of RESET.  With no interrupts enabled and all the
    downstream devices reset, and thus unable to send wakeup requests,
    this should be perfectly safe (even for non-NVIDIA hardware).
    
    The removal code in ohci-hcd hasn't been changed; it will still leave
    the controller in the RESET state.  As a result, if someone unloads
    ohci-hcd and then reloads it, the controller won't work again until
    the system is rebooted.  If anybody complains about this, the removal
    code can be updated similarly.
    
    This fixes Bugzilla #22052.
    
    Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Alan Stern committed with Andi Kleen Jul 15, 2011
  35. hwmon: (asus_atk0110) Fix memory leak

    [ upstream commit 0b8e77f ]
    
    The object returned by atk_gitm is dynamically allocated and must be
    freed.
    
    Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Cc: stable@kernel.org
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    tettamanti committed with Andi Kleen Jul 17, 2011