Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Feb 6, 2011
  1. Release 2.6.35.11

    Andi Kleen authored
    Release 2.6.35.11
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  2. @nbd168

    mac80211: fix initialization of skb->cb in ieee80211_subif_start_xmit

    nbd168 authored AK committed
    [ upstream commit 489ee91 ]
    
    The change 'mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs'
    added a check for copying the skb if it's shared, however the tx info variable
    still points at the cb of the old skb
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  3. mac80211: fix mesh forwarding when ratelimited too

    Milton Miller authored AK committed
    [ upstream commit 919bbad ]
    
    Commit b51aff0 said:
    
        Under memory pressure, the mac80211 mesh code
        may helpfully print a message that it failed
        to clone a mesh frame and then will proceed
        to crash trying to use it anyway. Fix that.
    
    Avoid the reference whenever the frame copy is unsuccessful
    regardless of the debug message being suppressed or printed.
    
    Cc: stable@kernel.org [2.6.27+]
    Signed-off-by: Milton Miller <miltonm@bga.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  4. revert-drm-radeon-kms-properly-compute-group_size-on-6xx-7xx

    Steve Conklin authored AK committed
    Revert drm/radeon/kms: properly compute group_size on 6xx/7xx
    
    From: Steve Conklin <sconklin@canonical.com>
    
    We discovered a regression for Radeon users in our latest proposed
    kernel for 2.6.35 (Maverick), and have isolated it to this patch:
    
    http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.35.y.git;a=commit;h=b8e9a4a45f8427837f4dba89
    +bda4d4e3f3a5c726
    
    We took that patch as part of 2.6.35.10, and one of our testers has
    reported that our build of that kernel also exhibits the problem.
    
    These are mainline kernels built with the Ubuntu configs.
    http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35.10-maverick/
    
    Our bug report is here:
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/703553
    
    Upstream bug report:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=24802
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  5. Input: i8042 - introduce 'notimeout' blacklist for Dell Vostro V13

    Jiri Kosina authored AK committed
    i8042 controller present in Dell Vostro V13 errorneously signals spurious
    timeouts.
    
    Introduce i8042.notimeout parameter for ignoring i8042-signalled timeouts
    and apply this quirk automatically for Dell Vostro V13, based on DMI match.
    
    In addition to that, this machine also needs to be added to nomux blacklist.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  6. @sgruszka

    mac80211: fix hard lockup in sta_addba_resp_timer_expired

    sgruszka authored AK committed
    Problem is 2.6.35 specific, bug was introduced in backport
    of upstream 4427148 commit.
    
    We can not call del_timer_sync(addba_resp_timer) from
    ___ieee80211_stop_tx_ba_session(), as this function can be called from
    that timer callback. To fix, simply use not synchronous del_timer().
    
    Resolve https://bugzilla.redhat.com/show_bug.cgi?id=667459
    
    Reported-and-tested-by: Mathieu Chouquet-Stringer <mathieu-acct@csetco.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  7. gspca - sonixj: Add a flag in the driver_info table

    Jean-Francois Moine authored AK committed
    commit c6c1433 upstream.
    
    Signed-off-by: Jean-François Moine <moinejf@free.fr>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  8. gspca - sonixj: Set the flag for some devices

    Jean-Francois Moine authored AK committed
    commit b2272a4 upstream.
    
    The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
    value as other webcams with the same sensor. For now, only two webcams have
    been so detected: the Microsoft's VX1000 and VX3000.
    
    Signed-off-by: Jean-François Moine <moinejf@free.fr>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  9. @utrace

    posix-cpu-timers: workaround to suppress the problems with mt exec

    utrace authored AK committed
    commit e0a7021 upstream.
    
    posix-cpu-timers.c correctly assumes that the dying process does
    posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD
    timers from signal->cpu_timers list.
    
    But, it also assumes that timer->it.cpu.task is always the group
    leader, and thus the dead ->task means the dead thread group.
    
    This is obviously not true after de_thread() changes the leader.
    After that almost every posix_cpu_timer_ method has problems.
    
    It is not simple to fix this bug correctly. First of all, I think
    that timer->it.cpu should use struct pid instead of task_struct.
    Also, the locking should be reworked completely. In particular,
    tasklist_lock should not be used at all. This all needs a lot of
    nontrivial and hard-to-test changes.
    
    Change __exit_signal() to do posix_cpu_timers_exit_group() when
    the old leader dies during exec. This is not the fix, just the
    temporary hack to hide the problem for 2.6.37 and stable. IOW,
    this is obviously wrong but this is what we currently have anyway:
    cpu timers do not work after mt exec.
    
    In theory this change adds another race. The exiting leader can
    detach the timers which were attached to the new leader. However,
    the window between de_thread() and release_task() is small, we
    can pretend that sys_timer_create() was called before de_thread().
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  10. @jjuhl

    x86/microcode: Fix double vfree() and remove redundant pointer checks…

    jjuhl authored AK committed
    … before vfree()
    
    commit 5cdd2de upstream.
    
    In arch/x86/kernel/microcode_intel.c::generic_load_microcode()
    we have  this:
    
    	while (leftover) {
    		...
    		if (get_ucode_data(mc, ucode_ptr, mc_size) ||
    		    microcode_sanity_check(mc) < 0) {
    			vfree(mc);
    			break;
    		}
    		...
    	}
    
    	if (mc)
    		vfree(mc);
    
    This will cause a double free of 'mc'. This patch fixes that by
    just  removing the vfree() call in the loop since 'mc' will be
    freed nicely just  after we break out of the loop.
    
    There's also a second change in the patch. I noticed a lot of
    checks for  pointers being NULL before passing them to vfree().
    That's completely  redundant since vfree() deals gracefully with
    being passed a NULL pointer.  Removing the redundant checks
    yields a nice size decrease for the object  file.
    
    Size before the patch:
       text    data     bss     dec     hex filename
       4578     240    1032    5850    16da arch/x86/kernel/microcode_intel.o
    Size after the patch:
       text    data     bss     dec     hex filename
       4489     240     984    5713    1651 arch/x86/kernel/microcode_intel.o
    
    Signed-off-by: Jesper Juhl <jj@chaosbits.net>
    Acked-by: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Cc: Shaohua Li <shaohua.li@intel.com>
    LKML-Reference: <alpine.LNX.2.00.1012251946100.10759@swampdragon.chaosbits.net>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead

    Martin K. Petersen authored AK committed
    commit e692cb6 upstream.
    
    When stacking devices, a request_queue is not always available. This
    forced us to have a no_cluster flag in the queue_limits that could be
    used as a carrier until the request_queue had been set up for a
    metadevice.
    
    There were several problems with that approach. First of all it was up
    to the stacking device to remember to set queue flag after stacking had
    completed. Also, the queue flag and the queue limits had to be kept in
    sync at all times. We got that wrong, which could lead to us issuing
    commands that went beyond the max scatterlist limit set by the driver.
    
    The proper fix is to avoid having two flags for tracking the same thing.
    We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the
    block layer merging functions. The queue_limit 'no_cluster' is turned
    into 'cluster' to avoid double negatives and to ease stacking.
    Clustering defaults to being enabled as before. The queue flag logic is
    removed from the stacking function, and explicitly setting the cluster
    flag is no longer necessary in DM and MD.
    
    Reported-by: Ed Lin <ed.lin@promise.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Acked-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  12. Sched: fix skip_clock_update optimization

    Mike Galbraith authored AK committed
    commit f26f9af upstream.
    
    idle_balance() drops/retakes rq->lock, leaving the previous task
    vulnerable to set_tsk_need_resched().  Clear it after we return
    from balancing instead, and in setup_thread_stack() as well, so
    no successfully descheduled or never scheduled task has it set.
    
    Need resched confused the skip_clock_update logic, which assumes
    that the next call to update_rq_clock() will come nearly immediately
    after being set.  Make the optimization robust against the waking
    a sleeper before it sucessfully deschedules case by checking that
    the current task has not been dequeued before setting the flag,
    since it is that useless clock update we're trying to save, and
    clear unconditionally in schedule() proper instead of conditionally
    in put_prev_task().
    
    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Reported-by: Bjoern B. Brandenburg <bbb.lst@gmail.com>
    Tested-by: Yong Zhang <yong.zhang0@gmail.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    LKML-Reference: <1291802742.1417.9.camel@marge.simson.net>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @crimsun

    ALSA: hda: Use LPIB quirk for Dell Inspiron m101z/1120

    crimsun authored AK committed
    commit e03fa05 upstream.
    
    Sjoerd Simons reports that, without using position_fix=1, recording
    experiences overruns. Work around that by applying the LPIB quirk
    for his hardware.
    
    Reported-and-tested-by: Sjoerd Simons <sjoerd@debian.org>
    Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  14. @jmberg

    mac80211: fix mesh forwarding

    jmberg authored AK committed
    commit b51aff0 upstream.
    
    Under memory pressure, the mac80211 mesh code
    may helpfully print a message that it failed
    to clone a mesh frame and then will proceed
    to crash trying to use it anyway. Fix that.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Acked-by: Javier Cardona <javier@cozybit.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  15. libata-sff: fix HSM_ST_ERR handling in __ata_sff_port_intr()

    Tejun Heo authored AK committed
    commit 687a993 upstream.
    
    While separating out BMDMA irq handler from SFF, commit c3b2889
    (libata-sff: separate out BMDMA irq handler) incorrectly made
    __ata_sff_port_intr() consider an IRQ to be an idle one if the host
    state was transitioned to HSM_ST_ERR by ata_bmdma_port_intr().
    
    This makes BMDMA drivers ignore IRQs reporting host bus error which
    leads to timeouts instead of triggering EH immediately.  Fix it by
    making __ata_sff_port_intr() consider the IRQ to be an idle one iff
    the state is HSM_ST_IDLE.  This is equivalent to adding HSM_ST_ERR to
    the "break"ing case but less error-prone.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Reported-by: Antonio Toma <antonio.toma@gmail.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. ima: fix add LSM rule bug

    Mimi Zohar authored AK committed
    commit 867c202 upstream.
    
    If security_filter_rule_init() doesn't return a rule, then not everything
    is as fine as the return code implies.
    
    This bug only occurs when the LSM (eg. SELinux) is disabled at runtime.
    
    Adding an empty LSM rule causes ima_match_rules() to always succeed,
    ignoring any remaining rules.
    
     default IMA TCB policy:
      # PROC_SUPER_MAGIC
      dont_measure fsmagic=0x9fa0
      # SYSFS_MAGIC
      dont_measure fsmagic=0x62656572
      # DEBUGFS_MAGIC
      dont_measure fsmagic=0x64626720
      # TMPFS_MAGIC
      dont_measure fsmagic=0x01021994
      # SECURITYFS_MAGIC
      dont_measure fsmagic=0x73636673
    
      < LSM specific rule >
      dont_measure obj_type=var_log_t
    
      measure func=BPRM_CHECK
      measure func=FILE_MMAP mask=MAY_EXEC
      measure func=FILE_CHECK mask=MAY_READ uid=0
    
    Thus without the patch, with the boot parameters 'tcb selinux=0', adding
    the above 'dont_measure obj_type=var_log_t' rule to the default IMA TCB
    measurement policy, would result in nothing being measured.  The patch
    prevents the default TCB policy from being replaced.
    
    Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Cc: James Morris <jmorris@namei.org>
    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
    Cc: David Safford <safford@watson.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. mv_xor: fix race in tasklet function

    Saeed Bishara authored AK committed
    commit 8333f65 upstream.
    
    use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function
    aquires the spin lock that needed to protect the drivers data.
    
    Signed-off-by: Saeed Bishara <saeed@marvell.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  18. sound: Prevent buffer overflow in OSS load_mixer_volumes

    Dan Rosenberg authored AK committed
    commit d81a12b upstream.
    
    The load_mixer_volumes() function, which can be triggered by
    unprivileged users via the SOUND_MIXER_SETLEVELS ioctl, is vulnerable to
    a buffer overflow.  Because the provided "name" argument isn't
    guaranteed to be NULL terminated at the expected 32 bytes, it's possible
    to overflow past the end of the last element in the mixer_vols array.
    Further exploitation can result in an arbitrary kernel write (via
    subsequent calls to load_mixer_volumes()) leading to privilege
    escalation, or arbitrary kernel reads via get_mixer_levels().  In
    addition, the strcmp() may leak bytes beyond the mixer_vols array.
    
    Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  19. drm/i915/dp: Fix I2C/EDID handling with active DisplayPort to DVI con…

    David Flynn authored AK committed
    …verter
    
    commit 8316f33 upstream.
    
    The DisplayPort standard (1.1a) states that:
      The I2C-over-AUX Reply field is valid only when Native AUX CH Reply
      field is AUX_ACK (00). When Native AUX CH Reply field is not 00, then,
      I2C-over-AUX Reply field must be 00 and be ignored.
    
    This fixes broken EDID reading when using an active DisplayPort to
    duallink DVI converter.  If the AUX CH replier chooses to defer the
    transaction, a short read occurs and erroneous data is returned as
    the i2c reply due to a lack of length checking and failure to check
    for AUX ACK.
    
    As a result, broken EDIDs can look like:
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
    00: bc bc bc ff bc bc bc ff bc bc bc ac bc bc bc 45    ???.???.???????E
    10: bc bc bc 10 bc bc bc 34 bc bc bc ee bc bc bc 4c    ???????4???????L
    20: bc bc bc 50 bc bc bc 00 bc bc bc 40 bc bc bc 00    ???P???.???@???.
    30: bc bc bc 01 bc bc bc 01 bc bc bc a0 bc bc bc 40    ???????????????@
    40: bc bc bc 00 bc bc bc 00 bc bc bc 00 bc bc bc 55    ???.???.???.???U
    50: bc bc bc 35 bc bc bc 31 bc bc bc 20 bc bc bc fc    ???5???1??? ????
    60: bc bc bc 4c bc bc bc 34 bc bc bc 46 bc bc bc 00    ???L???4???F???.
    70: bc bc bc 38 bc bc bc 11 bc bc bc 20 bc bc bc 20    ???8??????? ???
    80: bc bc bc ff bc bc bc ff bc bc bc ff bc bc bc ff    ???.???.???.???.
    ...
    
    which can lead to:
    [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder
    [drm:drm_edid_block_valid] *ERROR* Raw EDID:
    <3>30 30 30 30 30 30 30 32 38 32 30 32 63 63 31 61  000000028202cc1a
    <3>28 00 02 8c 00 00 00 00 18 00 00 00 00 00 00 00  (...............
    <3>20 4c 61 73 74 20 62 65 61 63 6f 6e 3a 20 33 32   Last beacon: 32
    <3>32 30 6d 73 20 61 67 6f 46 00 05 8c 00 00 00 00  20ms agoF.......
    <3>36 00 00 00 00 00 00 00 00 0c 57 69 2d 46 69 20  6.........Wi-Fi
    <3>52 6f 75 74 65 72 01 08 82 84 8b 96 24 30 48 6c  Router......$0Hl
    <3>03 01 01 06 02 00 00 2a 01 00 2f 01 00 32 04 0c  .......*../..2..
    <3>12 18 60 dd 09 00 10 18 02 00 00 01 00 00 18 00  ..`.............
    
    Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    [ickle: fix up some surrounding checkpatch warnings]
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. drm/radeon/kms: reorder display resume to avoid problems

    Alex Deucher authored AK committed
    commit a93f344 upstream.
    
    On resume, we were attemping to unblank the displays before the
    timing and plls had be reprogrammed which led to atom timeouts
    waiting for things that are not yet programmed.  Re-program
    the mode first, then reset the dpms state.
    
    This fixes the infamous atombios timeouts on resume.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  21. drm/radeon/kms: fix evergreen asic reset

    Alex Deucher authored AK committed
    commit 9f0c4f9 upstream.
    
    Only reset the grbm blocks, srbm tends to lock the GPU
    if not done properly and in most cases is not necessary.
    Also, no need to call asic init after reset the grbm blocks.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Reviewed-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. drm/radeon/kms/evergreen: reset the grbm blocks at resume and init

    Alex Deucher authored AK committed
    commit 86f5c9e upstream.
    
    This fixes module reloading and resume as the gfx block seems to
    be left in a bad state in some cases.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  23. @broonie

    mfd: Supply IRQ base for WM832x devices

    broonie authored AK committed
    commit bd7c72e upstream.
    
    Without this the IRQ base will not be correctly configured for the
    subdevices.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  24. @broonie

    mfd: Support additional parent IDs for wm831x

    broonie authored AK committed
    commit b93cef5 upstream.
    
    Some newer device revisions add a second parent ID. Support this in
    the device validity checks done at startup.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  25. arch/x86/oprofile/op_model_amd.c: Perform initialisation on a single CPU

    Robert Richter authored AK committed
    commit c7c2580 upstream.
    
    Disable preemption in init_ibs(). The function only checks the
    ibs capabilities and sets up pci devices (if necessary). It runs
    only on one cpu but operates with the local APIC and some MSRs,
    thus it is better to disable preemption.
    
    [    7.034377] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/483
    [    7.034385] caller is setup_APIC_eilvt+0x155/0x180
    [    7.034389] Pid: 483, comm: modprobe Not tainted 2.6.37-rc1-20101110+ #1
    [    7.034392] Call Trace:
    [    7.034400]  [<ffffffff812a2b72>] debug_smp_processor_id+0xd2/0xf0
    [    7.034404]  [<ffffffff8101e985>] setup_APIC_eilvt+0x155/0x180
    [ ... ]
    
    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22812
    
    Reported-by: <atswartz@gmail.com>
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Cc: oprofile-list@lists.sourceforge.net <oprofile-list@lists.sourceforge.net>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    Cc: Dan Carpenter <error27@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    LKML-Reference: <20110103111514.GM4739@erda.amd.com>
    [ small cleanups ]
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @ffainelli

    watchdog: Fix null pointer dereference while accessing rdc321x platfo…

    ffainelli authored AK committed
    …rm_data
    
    commit 3b3c1f2 upstream.
    
    rdc321x-wdt currently fetches its driver specific data by using the
    platform_device->platform_data pointer, this is wrong because the mfd
    device which registers our platform_device has been added using
    mfd_add_device() which sets the platform_device->driver_data pointer
    instead.
    
    Signed-off-by: Florian Fainelli <florian@openwrt.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  27. @ASDarwish

    RAMOOPS: Don't overflow over non-allocated regions

    ASDarwish authored AK committed
    commit 1873bb8 upstream.
    
    The current code mis-calculates the ramoops header size, leading to an
    overflow over the next record at best, or over a non-allocated region at
    worst.  Fix that calculation.
    
    Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
    Acked-by: Marco Stornelli <marco.stornelli@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  28. rtc: rs5c372: fix buffer size

    Wolfram Sang authored AK committed
    commit 1183649 upstream.
    
    Match the buffer size to the amount of initialized values.  Before, it was
    one too big and thus destroyed the neighbouring register causing the clock
    to run at false speeds.
    
    Reported-by: Andre van Rooyen <a.v.rooyen@sercom.nl>
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. fix freeing user_struct in user cache

    Hillf Danton authored AK committed
    commit 4ef9e11 upstream.
    
    When racing on adding into user cache, the new allocated from mm slab
    is freed without putting user namespace.
    
    Since the user namespace is already operated by getting, putting has
    to be issued.
    
    Signed-off-by: Hillf Danton <dhillf@gmail.com>
    Acked-by: Serge Hallyn <serge@hallyn.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  30. @tiwai

    mmc: Fix re-probing with PM_POST_RESTORE notification

    tiwai authored AK committed
    commit 274476f upstream.
    
    In the error-path where PM notifies PM_POST_RESTORE, the rescan-blockage
    should be cleared as well.  Otherwise it'll be never re-probed.
    
    Also, as a bonus, this fixes a bug in S4 with user-mode suspend in the
    current code, as it sends PM_POST_RESTORE instead of
    PM_POST_HIBERNATION wrongly.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  31. @noglitch

    mmc: atmel-mci: fix multiblock SDIO transfers

    noglitch authored AK committed
    commit 2f1d791 upstream.
    
    Based on report made by Yauhen in:
    "MMC: Fix multiblock SDIO transfers in AT91 MCI" patch,
    I report those changes to the brother driver: atmel-mci.
    
    So, this patch sets SDIO transfer types: SDIO block and SDIO byte
    transfers instead of using ordinary MMC block transfers.
    It is checking opcode for SDIO CMD53 and setting transfer
    type in MCI_CMDR register properly.
    
    Reported-by: Yauhen Kharuzhy <yauhen.kharuzhy@promwad.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  32. mmc: at91_mci: fix multiblock SDIO transfers

    Yauhen Kharuzhy authored AK committed
    commit a2255ff upstream.
    
    The AT91 MCI has special SDIO transfer types: SDIO block and SDIO byte
    transfers, but at91_mci driver doesn't use them and handles all SDIO
    transfers as ordinary MMC block transfers. This causes problems for
    multiple-block SDIO transfers (in particular for 256-bytes blocks).
    
    Fix this situation by checking the opcode for SDIO CMD53 and setting
    the transfer type in the AT91_MCI_CMDR register properly.
    
    This patch was tested with libertas SDIO driver: problem with TX
    timeouts on big packets was eliminated.
    
    Signed-off-by: Yauhen Kharuzhy <yauhen.kharuzhy@promwad.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  33. @dilinger

    cs5535-gpio: handle GPIO regs where higher (clear) bits are set

    dilinger authored AK committed
    commit 44658a1 upstream.
    
    The default for non-READ_BACK GPIO regs is to have the clear bits set;
    this means that our original errata fix was too simplistic.  This
    changes it to the following behavior:
    
     - when setting GPIOs, ignore the higher order bits (they're for
       clearing, we don't need to care about them).
    
     - when clearing GPIOs, keep all the bits, but unset (via XOR) the
       lower order bit that negates the clear bit that we care about.  That
       is, if we're clearing GPIO 26 (val = 0x04000000), we first XOR what's
       currently in the register with 0x0400 (GPIO 26's SET bit), and then
       OR that with the GPIO 26's CLEAR bit.
    
    Tested-by: Daniel Drake <dsd@laptop.org>
    Signed-off-by: Andres Salomon <dilinger@queued.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  34. @dilinger

    cs5535-gpio: don't apply errata #36 to edge detect GPIOs

    dilinger authored AK committed
    commit 0018516 upstream.
    
    The edge detect status GPIOs function differently from the other atomic
    model CS5536 GPIO registers; writing 1 to the high bits clears the GPIO,
    but writing 1 to the lower bits also clears the bit.
    
    This means that read-modify-write doesn't actually work for it, so don't
    apply the errata here.  If a negative edge status gets lost after
    resume..  well, we tried our best!
    
    Tested-by: Daniel Drake <dsd@laptop.org>
    Signed-off-by: Andres Salomon <dilinger@queued.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
  35. @ffainelli

    gpio: Fix null pointer dereference while accessing rdc321x platform_data

    ffainelli authored AK committed
    commit fa6469c upstream.
    
    rdc321x-gpio currently fetches its driver specific data by using the
    platform_device->platform_data pointer, this is wrong because the mfd
    device which registers our platform_device has been added using
    mfd_add_device() which sets the platform_device->driver_data pointer
    instead.
    
    Signed-off-by: Florian Fainelli <florian@openwrt.org>
    Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
Something went wrong with that request. Please try again.