Permalink
Commits on Mar 6, 2012
  1. Merge branch 'configs-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  2. configs-3.2: update TOI UI path

    Oleksandr Natalenko committed Mar 6, 2012
  3. Merge branch 'distro-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  4. distro-3.2: using kmod in Arch Linux

    Oleksandr Natalenko committed Mar 6, 2012
  5. Merge branch 'distro-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  6. distro-3.2: add Arch Linux specific files

    Oleksandr Natalenko committed Mar 6, 2012
  7. Merge branch 'configs-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  8. configs-3.2: update configs version

    Oleksandr Natalenko committed Mar 6, 2012
  9. Merge branch 'version-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  10. version-3.2: bump version to 3.2.6

    Oleksandr Natalenko committed Mar 6, 2012
  11. fix merge conflict

    Oleksandr Natalenko committed Mar 6, 2012
  12. Merge branch 'version-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  13. Merge branch 'configs-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  14. Merge branch 'imq-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  15. Merge branch 'bfq-3.2' into pf-3.2

    Oleksandr Natalenko committed Mar 6, 2012
  16. tuxonice-3.2: merge TOI for Linux v3.2.5

    Oleksandr Natalenko committed Mar 6, 2012
Commits on Mar 1, 2012
  1. Linux 3.2.9

    gregkh committed Mar 1, 2012
  2. cdrom: use copy_to_user() without the underscores

    Dan Carpenter committed with gregkh Feb 6, 2012
    commit 822bfa5 upstream.
    
    "nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap
    on 32 bit systems.  That would have been ok if we used the same wrapped
    value for the copy, but we use a shifted value.  We should just use the
    checked version of copy_to_user() because it's not going to make a
    difference to the speed.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. epoll: limit paths

    jibaron committed with gregkh Jan 13, 2012
    commit 28d82dc upstream.
    
    The current epoll code can be tickled to run basically indefinitely in
    both loop detection path check (on ep_insert()), and in the wakeup paths.
    The programs that tickle this behavior set up deeply linked networks of
    epoll file descriptors that cause the epoll algorithms to traverse them
    indefinitely.  A couple of these sample programs have been previously
    posted in this thread: https://lkml.org/lkml/2011/2/25/297.
    
    To fix the loop detection path check algorithms, I simply keep track of
    the epoll nodes that have been already visited.  Thus, the loop detection
    becomes proportional to the number of epoll file descriptor and links.
    This dramatically decreases the run-time of the loop check algorithm.  In
    one diabolical case I tried it reduced the run-time from 15 mintues (all
    in kernel time) to .3 seconds.
    
    Fixing the wakeup paths could be done at wakeup time in a similar manner
    by keeping track of nodes that have already been visited, but the
    complexity is harder, since there can be multiple wakeups on different
    cpus...Thus, I've opted to limit the number of possible wakeup paths when
    the paths are created.
    
    This is accomplished, by noting that the end file descriptor points that
    are found during the loop detection pass (from the newly added link), are
    actually the sources for wakeup events.  I keep a list of these file
    descriptors and limit the number and length of these paths that emanate
    from these 'source file descriptors'.  In the current implemetation I
    allow 1000 paths of length 1, 500 of length 2, 100 of length 3, 50 of
    length 4 and 10 of length 5.  Note that it is sufficient to check the
    'source file descriptors' reachable from the newly added link, since no
    other 'source file descriptors' will have newly added links.  This allows
    us to check only the wakeup paths that may have gotten too long, and not
    re-check all possible wakeup paths on the system.
    
    In terms of the path limit selection, I think its first worth noting that
    the most common case for epoll, is probably the model where you have 1
    epoll file descriptor that is monitoring n number of 'source file
    descriptors'.  In this case, each 'source file descriptor' has a 1 path of
    length 1.  Thus, I believe that the limits I'm proposing are quite
    reasonable and in fact may be too generous.  Thus, I'm hoping that the
    proposed limits will not prevent any workloads that currently work to
    fail.
    
    In terms of locking, I have extended the use of the 'epmutex' to all
    epoll_ctl add and remove operations.  Currently its only used in a subset
    of the add paths.  I need to hold the epmutex, so that we can correctly
    traverse a coherent graph, to check the number of paths.  I believe that
    this additional locking is probably ok, since its in the setup/teardown
    paths, and doesn't affect the running paths, but it certainly is going to
    add some extra overhead.  Also, worth noting is that the epmuex was
    recently added to the ep_ctl add operations in the initial path loop
    detection code using the argument that it was not on a critical path.
    
    Another thing to note here, is the length of epoll chains that is allowed.
    Currently, eventpoll.c defines:
    
    /* Maximum number of nesting allowed inside epoll sets */
    #define EP_MAX_NESTS 4
    
    This basically means that I am limited to a graph depth of 5 (EP_MAX_NESTS
    + 1).  However, this limit is currently only enforced during the loop
    check detection code, and only when the epoll file descriptors are added
    in a certain order.  Thus, this limit is currently easily bypassed.  The
    newly added check for wakeup paths, stricly limits the wakeup paths to a
    length of 5, regardless of the order in which ep's are linked together.
    Thus, a side-effect of the new code is a more consistent enforcement of
    the graph depth.
    
    Thus far, I've tested this, using the sample programs previously
    mentioned, which now either return quickly or return -EINVAL.  I've also
    testing using the piptest.c epoll tester, which showed no difference in
    performance.  I've also created a number of different epoll networks and
    tested that they behave as expectded.
    
    I believe this solves the original diabolical test cases, while still
    preserving the sane epoll nesting.
    
    Signed-off-by: Jason Baron <jbaron@redhat.com>
    Cc: Nelson Elhage <nelhage@ksplice.com>
    Cc: Davide Libenzi <davidel@xmailserver.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. epoll: ep_unregister_pollwait() can use the freed pwq->whead

    utrace committed with gregkh Feb 24, 2012
    commit 971316f upstream.
    
    signalfd_cleanup() ensures that ->signalfd_wqh is not used, but
    this is not enough. eppoll_entry->whead still points to the memory
    we are going to free, ep_unregister_pollwait()->remove_wait_queue()
    is obviously unsafe.
    
    Change ep_poll_callback(POLLFREE) to set eppoll_entry->whead = NULL,
    change ep_unregister_pollwait() to check pwq->whead != NULL under
    rcu_read_lock() before remove_wait_queue(). We add the new helper,
    ep_remove_wait_queue(), for this.
    
    This works because sighand_cachep is SLAB_DESTROY_BY_RCU and because
    ->signalfd_wqh is initialized in sighand_ctor(), not in copy_sighand.
    ep_unregister_pollwait()->remove_wait_queue() can play with already
    freed and potentially reused ->sighand, but this is fine. This memory
    must have the valid ->signalfd_wqh until rcu_read_unlock().
    
    Reported-by: Maxime Bizon <mbizon@freebox.fr>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. epoll: introduce POLLFREE to flush ->signalfd_wqh before kfree()

    utrace committed with gregkh Feb 24, 2012
    commit d80e731 upstream.
    
    This patch is intentionally incomplete to simplify the review.
    It ignores ep_unregister_pollwait() which plays with the same wqh.
    See the next change.
    
    epoll assumes that the EPOLL_CTL_ADD'ed file controls everything
    f_op->poll() needs. In particular it assumes that the wait queue
    can't go away until eventpoll_release(). This is not true in case
    of signalfd, the task which does EPOLL_CTL_ADD uses its ->sighand
    which is not connected to the file.
    
    This patch adds the special event, POLLFREE, currently only for
    epoll. It expects that init_poll_funcptr()'ed hook should do the
    necessary cleanup. Perhaps it should be defined as EPOLLFREE in
    eventpoll.
    
    __cleanup_sighand() is changed to do wake_up_poll(POLLFREE) if
    ->signalfd_wqh is not empty, we add the new signalfd_cleanup()
    helper.
    
    ep_poll_callback(POLLFREE) simply does list_del_init(task_list).
    This make this poll entry inconsistent, but we don't care. If you
    share epoll fd which contains our sigfd with another process you
    should blame yourself. signalfd is "really special". I simply do
    not know how we can define the "right" semantics if it used with
    epoll.
    
    The main problem is, epoll calls signalfd_poll() once to establish
    the connection with the wait queue, after that signalfd_poll(NULL)
    returns the different/inconsistent results depending on who does
    EPOLL_CTL_MOD/signalfd_read/etc. IOW: apart from sigmask, signalfd
    has nothing to do with the file, it works with the current thread.
    
    In short: this patch is the hack which tries to fix the symptoms.
    It also assumes that nobody can take tasklist_lock under epoll
    locks, this seems to be true.
    
    Note:
    
    	- we do not have wake_up_all_poll() but wake_up_poll()
    	  is fine, poll/epoll doesn't use WQ_FLAG_EXCLUSIVE.
    
    	- signalfd_cleanup() uses POLLHUP along with POLLFREE,
    	  we need a couple of simple changes in eventpoll.c to
    	  make sure it can't be "lost".
    
    Reported-by: Maxime Bizon <mbizon@freebox.fr>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. hwmon: (f75375s) Fix register write order when setting fans to full s…

    Nikolaus Schulz committed with gregkh Feb 22, 2012
    …peed
    
    commit c1c1a3d upstream.
    
    By hwmon sysfs interface convention, setting pwm_enable to zero sets a fan
    to full speed.  In the f75375s driver, this need be done by enabling
    manual fan control, plus duty mode for the F875387 chip, and then setting
    the maximum duty cycle.  Fix a bug where the two necessary register writes
    were swapped, effectively discarding the setting to full-speed.
    
    Signed-off-by: Nikolaus Schulz <mail@microschulz.de>
    Cc: Riku Voipio <riku.voipio@iki.fi>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. imon: don't wedge hardware after early callbacks

    jarodwilson committed with gregkh Jan 26, 2012
    commit 8791d63 upstream.
    
    This patch is just a minor update to one titled "imon: Input from ffdc
    device type ignored" from Corinna Vinschen. An earlier patch to prevent
    an oops when we got early callbacks also has the nasty side-effect of
    wedging imon hardware, as we don't acknowledge the urb. Rework the check
    slightly here to bypass processing the packet, as the driver isn't yet
    fully initialized, but still acknowlege the urb and submit a new rx_urb.
    Do this for both interfaces -- irrelevant for ffdc hardware, but
    relevant for newer hardware, though newer hardware doesn't spew the
    constant stream of data as soon as the hardware is initialized like the
    older ffdc devices, so they'd be less likely to trigger this anyway...
    
    Tested with both an ffdc device and an 0042 device.
    
    Reported-by: Corinna Vinschen <vinschen@redhat.com>
    Signed-off-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. hdpvr: fix race conditon during start of streaming

    jannau committed with gregkh Feb 2, 2012
    commit afa1595 upstream.
    
    status has to be set to STREAMING before the streaming worker is
    queued. hdpvr_transmit_buffers() will exit immediately otherwise.
    
    Reported-by: Joerg Desch <vvd.joede@googlemail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. can: sja1000: fix isr hang when hw is unplugged under load

    hartkopp committed with gregkh Feb 15, 2012
    commit a7762b1 upstream.
    
    In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
    hardware can cause an infinite loop in the common sja1000 isr.
    
    Use the already retrieved status register to indicate a possible hardware
    removal and double check by reading the mode register in sja1000_is_absent.
    
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Acked-by: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. builddeb: Don't create files in /tmp with predictable names

    bwhacks committed with gregkh Feb 15, 2012
    commit 6c63522 upstream.
    
    The current use of /tmp for file lists is insecure.  Put them under
    $objtree/debian instead.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Acked-by: maximilian attems <max@stro.at>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. davinci_emac: Do not free all rx dma descriptors during init

    Christian Riesch committed with gregkh Feb 23, 2012
    commit 5d69703 upstream.
    
    This patch fixes a regression that was introduced by
    
    commit 0a5f384
    davinci_emac: Add Carrier Link OK check in Davinci RX Handler
    
    Said commit adds a check whether the carrier link is ok. If the link is
    not ok, the skb is freed and no new dma descriptor added to the rx dma
    channel. This causes trouble during initialization when the carrier
    status has not yet been updated. If a lot of packets are received while
    netif_carrier_ok returns false, all dma descriptors are freed and the
    rx dma transfer is stopped.
    
    The bug occurs when the board is connected to a network with lots of
    traffic and the ifconfig down/up is done, e.g., when reconfiguring
    the interface with DHCP.
    
    The bug can be reproduced by flood pinging the davinci board while doing
    ifconfig eth0 down
    ifconfig eth0 up
    on the board.
    
    After that, the rx path stops working and the overrun value reported
    by ifconfig is counting up.
    
    This patch reverts commit 0a5f384
    and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.
    
    Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
    Cc: Cyril Chemparathy <cyril@ti.com>
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Tested-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. jme: Fix FIFO flush issue

    cooldavid committed with gregkh Feb 22, 2012
    commit ba9adbe upstream.
    
    Set the RX FIFO flush watermark lower.
    According to Federico and JMicron's reply,
    setting it to 16QW would be stable on most platforms.
    Otherwise, user might experience packet drop issue.
    
    Reported-by: Federico Quagliata <federico@quagliata.org>
    Fixed-by: Federico Quagliata <federico@quagliata.org>
    Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. ipvs: fix matching of fwmark templates during scheduling

    horms committed with gregkh Jan 27, 2012
    commit e0aac52 upstream.
    
    	Commit f11017e (2.6.37)
    moved the fwmark variable in subcontext that is invalidated before
    reaching the ip_vs_ct_in_get call. As vaddr is provided as pointer
    in the param structure make sure the fwmark variable is in
    same context. As the fwmark templates can not be matched,
    more and more template connections are created and the
    controlled connections can not go to single real server.
    
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. scsi_pm: Fix bug in the SCSI power management handler

    AlanStern committed with gregkh Feb 17, 2012
    commit fea6d60 upstream.
    
    This patch (as1520) fixes a bug in the SCSI layer's power management
    implementation.
    
    LUN scanning can be carried out asynchronously in do_scan_async(), and
    sd uses an asynchronous thread for the time-consuming parts of disk
    probing in sd_probe_async().  Currently nothing coordinates these
    async threads with system sleep transitions; they can and do attempt
    to continue scanning/probing SCSI devices even after the host adapter
    has been suspended.  As one might expect, the outcome is not ideal.
    
    This is what the "prepare" stage of system suspend was created for.
    After the prepare callback has been called for a host, target, or
    device, drivers are not allowed to register any children underneath
    them.  Currently the SCSI prepare callback is not implemented; this
    patch rectifies that omission.
    
    For SCSI hosts, the prepare routine calls scsi_complete_async_scans()
    to wait until async scanning is finished.  It might be slightly more
    efficient to wait only until the host in question has been scanned,
    but there's currently no way to do that.  Besides, during a sleep
    transition we will ultimately have to wait until all the host scanning
    has finished anyway.
    
    For SCSI devices, the prepare routine calls async_synchronize_full()
    to wait until sd probing is finished.  The routine does nothing for
    SCSI targets, because asynchronous target scanning is done only as
    part of host scanning.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. scsi_scan: Fix 'Poison overwritten' warning caused by using freed 'sh…

    Huajun Li committed with gregkh Feb 12, 2012
    …ost'
    
    commit 267a6ad upstream.
    
    In do_scan_async(), calling scsi_autopm_put_host(shost) may reference
    freed shost, and cause Posison overwitten warning.
    Yes, this case can happen, for example, an USB is disconnected just
    when do_scan_async() thread starts to run, then scsi_host_put() called
    in scsi_finish_async_scan() will lead to shost be freed(because the
    refcount of shost->shost_gendev decreases to 1 after USB disconnects),
    at this point, if references shost again, system will show following
    warning msg.
    
    To make scsi_autopm_put_host(shost) always reference a valid shost,
    put it just before scsi_host_put() in function
    scsi_finish_async_scan().
    
    [  299.281565] =============================================================================
    [  299.281634] BUG kmalloc-4096 (Tainted: G          I ): Poison overwritten
    [  299.281682] -----------------------------------------------------------------------------
    [  299.281684]
    [  299.281752] INFO: 0xffff880056c305d0-0xffff880056c305d0. First byte
    0x6a instead of 0x6b
    [  299.281816] INFO: Allocated in scsi_host_alloc+0x4a/0x490 age=1688
    cpu=1 pid=2004
    [  299.281870] 	__slab_alloc+0x617/0x6c1
    [  299.281901] 	__kmalloc+0x28c/0x2e0
    [  299.281931] 	scsi_host_alloc+0x4a/0x490
    [  299.281966] 	usb_stor_probe1+0x5b/0xc40 [usb_storage]
    [  299.282010] 	storage_probe+0xa4/0xe0 [usb_storage]
    [  299.282062] 	usb_probe_interface+0x172/0x330 [usbcore]
    [  299.282105] 	driver_probe_device+0x257/0x3b0
    [  299.282138] 	__driver_attach+0x103/0x110
    [  299.282171] 	bus_for_each_dev+0x8e/0xe0
    [  299.282201] 	driver_attach+0x26/0x30
    [  299.282230] 	bus_add_driver+0x1c4/0x430
    [  299.282260] 	driver_register+0xb6/0x230
    [  299.282298] 	usb_register_driver+0xe5/0x270 [usbcore]
    [  299.282337] 	0xffffffffa04ab03d
    [  299.282364] 	do_one_initcall+0x47/0x230
    [  299.282396] 	sys_init_module+0xa0f/0x1fe0
    [  299.282429] INFO: Freed in scsi_host_dev_release+0x18a/0x1d0 age=85
    cpu=0 pid=2008
    [  299.282482] 	__slab_free+0x3c/0x2a1
    [  299.282510] 	kfree+0x296/0x310
    [  299.282536] 	scsi_host_dev_release+0x18a/0x1d0
    [  299.282574] 	device_release+0x74/0x100
    [  299.282606] 	kobject_release+0xc7/0x2a0
    [  299.282637] 	kobject_put+0x54/0xa0
    [  299.282668] 	put_device+0x27/0x40
    [  299.282694] 	scsi_host_put+0x1d/0x30
    [  299.282723] 	do_scan_async+0x1fc/0x2b0
    [  299.282753] 	kthread+0xdf/0xf0
    [  299.282782] 	kernel_thread_helper+0x4/0x10
    [  299.282817] INFO: Slab 0xffffea00015b0c00 objects=7 used=7 fp=0x
          (null) flags=0x100000000004080
    [  299.282882] INFO: Object 0xffff880056c30000 @offset=0 fp=0x          (null)
    [  299.282884]
    ...
    
    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. genirq: Handle pending irqs in irq_startup()

    Thomas Gleixner committed with gregkh Feb 8, 2012
    commit b4bc724 upstream.
    
    An interrupt might be pending when irq_startup() is called, but the
    startup code does not invoke the resend logic. In some cases this
    prevents the device from issuing another interrupt which renders the
    device non functional.
    
    Call the resend function in irq_startup() to keep things going.
    
    Reported-and-tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. genirq: Unmask oneshot irqs when thread was not woken

    Thomas Gleixner committed with gregkh Feb 7, 2012
    commit ac56376 upstream.
    
    When the primary handler of an interrupt which is marked IRQ_ONESHOT
    returns IRQ_HANDLED or IRQ_NONE, then the interrupt thread is not
    woken and the unmask logic of the interrupt line is never
    invoked. This keeps the interrupt masked forever.
    
    This was not noticed as most IRQ_ONESHOT users wake the thread
    unconditionally (usually because they cannot access the underlying
    device from hard interrupt context). Though this behaviour was nowhere
    documented and not necessarily intentional. Some drivers can avoid the
    thread wakeup in certain cases and run into the situation where the
    interrupt line s kept masked.
    
    Handle it gracefully.
    
    Reported-and-tested-by: Lothar Wassmann <lw@karo-electronics.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. ath9k: stop on rates with idx -1 in ath9k rate control's .tx_status

    proski committed with gregkh Feb 11, 2012
    commit 2504a64 upstream.
    
    Rate control algorithms are supposed to stop processing when they
    encounter a rate with the index -1.  Checking for rate->count not being
    zero is not enough.
    
    Allowing a rate with negative index leads to memory corruption in
    ath_debug_stat_rc().
    
    One consequence of the bug is discussed at
    https://bugzilla.redhat.com/show_bug.cgi?id=768639
    
    Signed-off-by: Pavel Roskin <proski@gnu.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. x86/amd: Fix L1i and L2 cache sharing information for AMD family 15h …

    Andreas Herrmann committed with gregkh Feb 8, 2012
    …processors
    
    commit 32c3233 upstream.
    
    For L1 instruction cache and L2 cache the shared CPU information
    is wrong. On current AMD family 15h CPUs those caches are shared
    between both cores of a compute unit.
    
    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=42607
    
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Cc: Petkov Borislav <Borislav.Petkov@amd.com>
    Cc: Dave Jones <davej@redhat.com>
    Link: http://lkml.kernel.org/r/20120208195229.GA17523@alberich.amd.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>