Permalink
Commits on Jul 19, 2012
  1. Linux 3.0.38

    gregkh committed Jul 19, 2012
  2. timekeeping: Add missing update call in timekeeping_resume()

    This is a backport of 3e99713
    
    The leap second rework unearthed another issue of inconsistent data.
    
    On timekeeping_resume() the timekeeper data is updated, but nothing
    calls timekeeping_update(), so now the update code in the timer
    interrupt sees stale values.
    
    This has been the case before those changes, but then the timer
    interrupt was using stale data as well so this went unnoticed for quite
    some time.
    
    Add the missing update call, so all the data is consistent everywhere.
    
    Reported-by: Andreas Schwab <schwab@linux-m68k.org>
    Reported-and-tested-by: "Rafael J. Wysocki" <rjw@sisk.pl>
    Reported-and-tested-by: Martin Steigerwald <Martin@lichtvoll.de>
    Cc: John Stultz <johnstul@us.ibm.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
    Cc: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Thomas Gleixner committed with gregkh Jul 17, 2012
  3. hrtimer: Update hrtimer base offsets each hrtimer_interrupt

    This is a backport of 5baefd6
    
    The update of the hrtimer base offsets on all cpus cannot be made
    atomically from the timekeeper.lock held and interrupt disabled region
    as smp function calls are not allowed there.
    
    clock_was_set(), which enforces the update on all cpus, is called
    either from preemptible process context in case of do_settimeofday()
    or from the softirq context when the offset modification happened in
    the timer interrupt itself due to a leap second.
    
    In both cases there is a race window for an hrtimer interrupt between
    dropping timekeeper lock, enabling interrupts and clock_was_set()
    issuing the updates. Any interrupt which arrives in that window will
    see the new time but operate on stale offsets.
    
    So we need to make sure that an hrtimer interrupt always sees a
    consistent state of time and offsets.
    
    ktime_get_update_offsets() allows us to get the current monotonic time
    and update the per cpu hrtimer base offsets from hrtimer_interrupt()
    to capture a consistent state of monotonic time and the offsets. The
    function replaces the existing ktime_get() calls in hrtimer_interrupt().
    
    The overhead of the new function vs. ktime_get() is minimal as it just
    adds two store operations.
    
    This ensures that any changes to realtime or boottime offsets are
    noticed and stored into the per-cpu hrtimer base structures, prior to
    any hrtimer expiration and guarantees that timers are not expired early.
    
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Prarit Bhargava <prarit@redhat.com>
    Link: http://lkml.kernel.org/r/1341960205-56738-8-git-send-email-johnstul@us.ibm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    John Stultz committed with gregkh Jul 17, 2012
  4. timekeeping: Provide hrtimer update function

    This is a backport of f6c06ab
    
    To finally fix the infamous leap second issue and other race windows
    caused by functions which change the offsets between the various time
    bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a
    function which atomically gets the current monotonic time and updates
    the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic
    overhead. The previous patch which provides ktime_t offsets allows us
    to make this function almost as cheap as ktime_get() which is going to
    be replaced in hrtimer_interrupt().
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Link: http://lkml.kernel.org/r/1341960205-56738-7-git-send-email-johnstul@us.ibm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Thomas Gleixner committed with gregkh Jul 17, 2012
  5. hrtimers: Move lock held region in hrtimer_interrupt()

    This is a backport of 196951e
    
    We need to update the base offsets from this code and we need to do
    that under base->lock. Move the lock held region around the
    ktime_get() calls. The ktime_get() calls are going to be replaced with
    a function which gets the time and the offsets atomically.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Link: http://lkml.kernel.org/r/1341960205-56738-6-git-send-email-johnstul@us.ibm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Thomas Gleixner committed with gregkh Jul 17, 2012
  6. timekeeping: Maintain ktime_t based offsets for hrtimers

    This is a backport of 5b9fe75
    
    We need to update the hrtimer clock offsets from the hrtimer interrupt
    context. To avoid conversions from timespec to ktime_t maintain a
    ktime_t based representation of those offsets in the timekeeper. This
    puts the conversion overhead into the code which updates the
    underlying offsets and provides fast accessible values in the hrtimer
    interrupt.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Prarit Bhargava <prarit@redhat.com>
    Link: http://lkml.kernel.org/r/1341960205-56738-4-git-send-email-johnstul@us.ibm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Thomas Gleixner committed with gregkh Jul 17, 2012
  7. timekeeping: Fix leapsecond triggered load spike issue

    This is a backport of 4873fa0
    
    The timekeeping code misses an update of the hrtimer subsystem after a
    leap second happened. Due to that timers based on CLOCK_REALTIME are
    either expiring a second early or late depending on whether a leap
    second has been inserted or deleted until an operation is initiated
    which causes that update. Unless the update happens by some other
    means this discrepancy between the timekeeping and the hrtimer data
    stays forever and timers are expired either early or late.
    
    The reported immediate workaround - $ data -s "`date`" - is causing a
    call to clock_was_set() which updates the hrtimer data structures.
    See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix
    
    Add the missing clock_was_set() call to update_wall_time() in case of
    a leap second event. The actual update is deferred to softirq context
    as the necessary smp function call cannot be invoked from hard
    interrupt context.
    
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Reported-by: Jan Engelhardt <jengelh@inai.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Prarit Bhargava <prarit@redhat.com>
    Link: http://lkml.kernel.org/r/1341960205-56738-3-git-send-email-johnstul@us.ibm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    John Stultz committed with gregkh Jul 17, 2012
  8. hrtimer: Provide clock_was_set_delayed()

    This is a backport of f55a6fa
    
    clock_was_set() cannot be called from hard interrupt context because
    it calls on_each_cpu().
    
    For fixing the widely reported leap seconds issue it is necessary to
    call it from hard interrupt context, i.e. the timer tick code, which
    does the timekeeping updates.
    
    Provide a new function which denotes it in the hrtimer cpu base
    structure of the cpu on which it is called and raise the hrtimer
    softirq. We then execute the clock_was_set() notificiation from
    softirq context in run_hrtimer_softirq(). The hrtimer softirq is
    rarely used, so polling the flag there is not a performance issue.
    
    [ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
      rid of all this ifdeffery ASAP ]
    
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Reported-by: Jan Engelhardt <jengelh@inai.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Prarit Bhargava <prarit@redhat.com>
    Link: http://lkml.kernel.org/r/1341960205-56738-2-git-send-email-johnstul@us.ibm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    John Stultz committed with gregkh Jul 17, 2012
  9. time: Move common updates to a function

    This is a backport of cc06268
    
    While not a bugfix itself, it allows following fixes to backport
    in a more straightforward manner.
    
    CC: Thomas Gleixner <tglx@linutronix.de>
    CC: Eric Dumazet <eric.dumazet@gmail.com>
    CC: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Thomas Gleixner committed with gregkh Jul 17, 2012
  10. timekeeping: Fix CLOCK_MONOTONIC inconsistency during leapsecond

    This is a backport of fad0c66
    which resolves a bug the previous commit.
    
    Commit 6b43ae8 (ntp: Fix leap-second hrtimer livelock) broke the
    leapsecond update of CLOCK_MONOTONIC. The missing leapsecond update to
    wall_to_monotonic causes discontinuities in CLOCK_MONOTONIC.
    
    Adjust wall_to_monotonic when NTP inserted a leapsecond.
    
    Reported-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Tested-by: Richard Cochran <richardcochran@gmail.com>
    Link: http://lkml.kernel.org/r/1338400497-12420-1-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    johnstultz-work committed with gregkh Jul 17, 2012
  11. ntp: Correct TAI offset during leap second

    This is a backport of dd48d70
    
    When repeating a UTC time value during a leap second (when the UTC
    time should be 23:59:60), the TAI timescale should not stop. The kernel
    NTP code increments the TAI offset one second too late. This patch fixes
    the issue by incrementing the offset during the leap second itself.
    
    Signed-off-by: Richard Cochran <richardcochran@gmail.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    richardcochran committed with gregkh Jul 17, 2012
  12. ntp: Fix leap-second hrtimer livelock

    This is a backport of 6b43ae8
    
    This should have been backported when it was commited, but I
    mistook the problem as requiring the ntp_lock changes
    that landed in 3.4 in order for it to occur.
    
    Unfortunately the same issue can happen (with only one cpu)
    as follows:
    do_adjtimex()
     write_seqlock_irq(&xtime_lock);
      process_adjtimex_modes()
       process_adj_status()
        ntp_start_leap_timer()
         hrtimer_start()
          hrtimer_reprogram()
           tick_program_event()
            clockevents_program_event()
             ktime_get()
              seq = req_seqbegin(xtime_lock); [DEADLOCK]
    
    This deadlock will no always occur, as it requires the
    leap_timer to force a hrtimer_reprogram which only happens
    if its set and there's no sooner timer to expire.
    
    NOTE: This patch, being faithful to the original commit,
    introduces a bug (we don't update wall_to_monotonic),
    which will be resovled by backporting a following fix.
    
    Original commit message below:
    
    Since commit 7dffa3c the ntp
    subsystem has used an hrtimer for triggering the leapsecond
    adjustment. However, this can cause a potential livelock.
    
    Thomas diagnosed this as the following pattern:
    CPU 0                                                    CPU 1
    do_adjtimex()
      spin_lock_irq(&ntp_lock);
        process_adjtimex_modes();				 timer_interrupt()
          process_adj_status();                                do_timer()
            ntp_start_leap_timer();                             write_lock(&xtime_lock);
              hrtimer_start();                                  update_wall_time();
                 hrtimer_reprogram();                            ntp_tick_length()
                   tick_program_event()                            spin_lock(&ntp_lock);
                     clockevents_program_event()
    		   ktime_get()
                         seq = req_seqbegin(xtime_lock);
    
    This patch tries to avoid the problem by reverting back to not using
    an hrtimer to inject leapseconds, and instead we handle the leapsecond
    processing in the second_overflow() function.
    
    The downside to this change is that on systems that support highres
    timers, the leap second processing will occur on a HZ tick boundary,
    (ie: ~1-10ms, depending on HZ)  after the leap second instead of
    possibly sooner (~34us in my tests w/ x86_64 lapic).
    
    This patch applies on top of tip/timers/core.
    
    CC: Sasha Levin <levinsasha928@gmail.com>
    CC: Thomas Gleixner <tglx@linutronix.de>
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Diagnoised-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Sasha Levin <levinsasha928@gmail.com>
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    johnstultz-work committed with gregkh Jul 17, 2012
  13. cfg80211: check iface combinations only when iface is running

    commit f8cdddb upstream.
    
    Don't validate interface combinations on a stopped
    interface. Otherwise we might end up being able to
    create a new interface with a certain type, but
    won't be able to change an existing interface
    into that type.
    
    This also skips some other functions when
    interface is stopped and changing interface type.
    
    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [Fixes regression introduced by cherry pick of 463454b]
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Michal Kazior committed with gregkh Jun 8, 2012
  14. tcp: drop SYN+FIN messages

    commit fdf5af0 upstream.
    
    Denys Fedoryshchenko reported that SYN+FIN attacks were bringing his
    linux machines to their limits.
    
    Dont call conn_request() if the TCP flags includes SYN flag
    
    Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Eric Dumazet committed with gregkh Dec 2, 2011
  15. Input: xpad - add Andamiro Pump It Up pad

    commit e76b8ee upstream.
    
    I couldn't find the vendor ID in any of the online databases, but this
    mat has a Pump It Up logo on the top side of the controller compartment,
    and a disclaimer stating that Andamiro will not be liable on the bottom.
    
    Signed-off-by: Yuri Khan <yurivkhan@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    yurikhan committed with gregkh Jul 12, 2012
  16. e1000e: Correct link check logic for 82571 serdes

    commit d0efa8f upstream.
    
    SYNCH bit and IV bit of RXCW register are sticky. Before examining these bits,
    RXCW should be read twice to filter out one-time false events and have correct
    values for these bits. Incorrect values of these bits in link check logic can
    cause weird link stability issues if auto-negotiation fails.
    
    Reported-by: Dean Nelson <dnelson@redhat.com>
    Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
    Reviewed-by: Bruce Allan <bruce.w.allan@intel.com>
    Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tushar Dave committed with gregkh Jul 12, 2012
  17. rt2x00usb: fix indexes ordering on RX queue kick

    commit efd8211 upstream.
    
    On rt2x00_dmastart() we increase index specified by Q_INDEX and on
    rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries
    between Q_INDEX_DONE and Q_INDEX are those we currently process in the
    hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can
    submit to the hardware.
    
    According to that fix rt2x00usb_kick_queue(), as we need to submit RX
    entries that are not processed by the hardware. It worked before only
    for empty queue, otherwise was broken.
    
    Note that for TX queues indexes ordering are ok. We need to kick entries
    that have filled skb, but was not submitted to the hardware, i.e.
    started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.
    
    From practical standpoint this fixes RX queue stall, usually reproducible
    in AP mode, like for example reported here:
    https://bugzilla.redhat.com/show_bug.cgi?id=828824
    
    Reported-and-tested-by: Franco Miceli <fmiceli@plan.ceibal.edu.uy>
    Reported-and-tested-by: Tom Horsley <horsley1953@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    sgruszka committed with gregkh Jul 4, 2012
  18. fifo: Do not restart open() if it already found a partner

    commit 05d290d upstream.
    
    If a parent and child process open the two ends of a fifo, and the
    child immediately exits, the parent may receive a SIGCHLD before its
    open() returns.  In that case, we need to make sure that open() will
    return successfully after the SIGCHLD handler returns, instead of
    throwing EINTR or being restarted.  Otherwise, the restarted open()
    would incorrectly wait for a second partner on the other end.
    
    The following test demonstrates the EINTR that was wrongly thrown from
    the parent’s open().  Change .sa_flags = 0 to .sa_flags = SA_RESTART
    to see a deadlock instead, in which the restarted open() waits for a
    second reader that will never come.  (On my systems, this happens
    pretty reliably within about 5 to 500 iterations.  Others report that
    it manages to loop ~forever sometimes; YMMV.)
    
      #include <sys/stat.h>
      #include <sys/types.h>
      #include <sys/wait.h>
      #include <fcntl.h>
      #include <signal.h>
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
    
      #define CHECK(x) do if ((x) == -1) {perror(#x); abort();} while(0)
    
      void handler(int signum) {}
    
      int main()
      {
          struct sigaction act = {.sa_handler = handler, .sa_flags = 0};
          CHECK(sigaction(SIGCHLD, &act, NULL));
          CHECK(mknod("fifo", S_IFIFO | S_IRWXU, 0));
          for (;;) {
              int fd;
              pid_t pid;
              putc('.', stderr);
              CHECK(pid = fork());
              if (pid == 0) {
                  CHECK(fd = open("fifo", O_RDONLY));
                  _exit(0);
              }
              CHECK(fd = open("fifo", O_WRONLY));
              CHECK(close(fd));
              CHECK(waitpid(pid, NULL, 0));
          }
      }
    
    This is what I suspect was causing the Git test suite to fail in
    t9010-svn-fe.sh:
    
    	http://bugs.debian.org/678852
    
    Signed-off-by: Anders Kaseorg <andersk@mit.edu>
    Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    andersk committed with gregkh Jul 15, 2012
  19. intel_ips: blacklist HP ProBook laptops

    commit 88ca518 upstream.
    
    intel_ips driver spews the warning message
      "ME failed to update for more than 1s, likely hung"
    at each second endlessly on HP ProBook laptops with IronLake.
    
    As this has never worked, better to blacklist the driver for now.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    tiwai committed with gregkh Jun 25, 2012
  20. ARM: SAMSUNG: fix race in s3c_adc_start for ADC

    commit 8265981 upstream.
    
    Checking for adc->ts_pend already claimed should be done with the
    lock held.
    
    Signed-off-by: Todd Poynor <toddpoynor@google.com>
    Acked-by: Ben Dooks <ben-linux@fluff.org>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    toddpoynor committed with gregkh Jul 13, 2012
  21. mtd: nandsim: don't open code a do_div helper

    commit 596fd46 upstream.
    
    We don't need to open code the divide function, just use div_u64 that
    already exists and do the same job. While this is a straightforward
    clean up, there is more to that, the real motivation for this.
    
    While building on a cross compiling environment in armel, using gcc
    4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5), I was getting the following build
    error:
    
    ERROR: "__aeabi_uldivmod" [drivers/mtd/nand/nandsim.ko] undefined!
    
    After investigating with objdump and hand built assembly version
    generated with the compiler, I narrowed __aeabi_uldivmod as being
    generated from the divide function. When nandsim.c is built with
    -fno-inline-functions-called-once, that happens when
    CONFIG_DEBUG_SECTION_MISMATCH is enabled, the do_div optimization in
    arch/arm/include/asm/div64.h doesn't work as expected with the open
    coded divide function: even if the do_div we are using doesn't have a
    constant divisor, the compiler still includes the else parts of the
    optimized do_div macro, and translates the divisions there to use
    __aeabi_uldivmod, instead of only calling __do_div_asm -> __do_div64 and
    optimizing/removing everything else out.
    
    So to reproduce, gcc 4.6 plus CONFIG_DEBUG_SECTION_MISMATCH=y and
    CONFIG_MTD_NAND_NANDSIM=m should do it, building on armel.
    
    After this change, the compiler does the intended thing even with
    -fno-inline-functions-called-once, and optimizes out as expected the
    constant handling in the optimized do_div on arm. As this also avoids a
    build issue, I'm marking for Stable, as I think is applicable for this
    case.
    
    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Acked-by: Nicolas Pitre <nico@linaro.org>
    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>
    Herton Ronaldo Krzesinski committed with gregkh May 16, 2012
  22. media: dvb-core: Release semaphore on error path dvb_register_device()

    commit 82163ed upstream.
    
    There is a missing "up_write()" here. Semaphore should be released
    before returning error value.
    
    Signed-off-by: Santosh Nayak <santoshprasadnayak@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Santosh Nayak committed with gregkh Jun 23, 2012
  23. block: fix infinite loop in __getblk_slow

    commit 91f68c8 upstream.
    
    Commit 080399a ("block: don't mark buffers beyond end of disk as
    mapped") exposed a bug in __getblk_slow that causes mount to hang as it
    loops infinitely waiting for a buffer that lies beyond the end of the
    disk to become uptodate.
    
    The problem was initially reported by Torsten Hilbrich here:
    
        https://lkml.org/lkml/2012/6/18/54
    
    and also reported independently here:
    
        http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511
    
    and then Richard W.M.  Jones and Marcos Mello noted a few separate
    bugzillas also associated with the same issue.  This patch has been
    confirmed to fix:
    
        https://bugzilla.redhat.com/show_bug.cgi?id=835019
    
    The main problem is here, in __getblk_slow:
    
            for (;;) {
                    struct buffer_head * bh;
                    int ret;
    
                    bh = __find_get_block(bdev, block, size);
                    if (bh)
                            return bh;
    
                    ret = grow_buffers(bdev, block, size);
                    if (ret < 0)
                            return NULL;
                    if (ret == 0)
                            free_more_memory();
            }
    
    __find_get_block does not find the block, since it will not be marked as
    mapped, and so grow_buffers is called to fill in the buffers for the
    associated page.  I believe the for (;;) loop is there primarily to
    retry in the case of memory pressure keeping grow_buffers from
    succeeding.  However, we also continue to loop for other cases, like the
    block lying beond the end of the disk.  So, the fix I came up with is to
    only loop when grow_buffers fails due to memory allocation issues
    (return value of 0).
    
    The attached patch was tested by myself, Torsten, and Rich, and was
    found to resolve the problem in call cases.
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Reported-and-Tested-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
    Tested-by: Richard W.M. Jones <rjones@redhat.com>
    Reviewed-by: Josh Boyer <jwboyer@redhat.com>
    [ Jens is on vacation, taking this directly  - Linus ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    JeffMoyer committed with gregkh Jul 12, 2012
  24. hwmon: (it87) Preserve configuration register bits on init

    commit 41002f8 upstream.
    
    We were accidentally losing one bit in the configuration register on
    device initialization. It was reported to freeze one specific system
    right away. Properly preserve all bits we don't explicitly want to
    change in order to prevent that.
    
    Reported-by: Stevie Trujillo <stevie.trujillo@gmail.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Jean Delvare committed with gregkh Jul 12, 2012
Commits on Jul 16, 2012
  1. Linux 3.0.37

    gregkh committed Jul 16, 2012
  2. ACPI: Remove one board specific WARN when ignoring timer overriding

    commit 7f68b4c upstream.
    
    Current WARN msg is only for the ati_ixp4x0 board, while this function
    is used by mulitple platforms. So this one board specific warning
    is not appropriate any more.
    
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ftang1 committed with gregkh Jun 4, 2012
  3. ACPI: Make acpi_skip_timer_override cover all source_irq==0 cases

    commit ae10ccd upstream.
    
    Currently when acpi_skip_timer_override is set, it only cover the
    (source_irq == 0 && global_irq == 2) cases. While there is also
    platform which need use this option and its global_irq is not 2.
    This patch will extend acpi_skip_timer_override to cover all
    timer overriding cases as long as the source irq is 0.
    
    This is the first part of a fix to kernel bug bugzilla 40002:
    	"IRQ 0 assigned to VGA"
    https://bugzilla.kernel.org/show_bug.cgi?id=40002
    
    Reported-and-tested-by: Szymon Kowalczyk <fazerxlo@o2.pl>
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ftang1 committed with gregkh Jun 4, 2012
  4. mm: Hold a file reference in madvise_remove

    commit 9ab4233 upstream.
    
    Otherwise the code races with munmap (causing a use-after-free
    of the vma) or with close (causing a use-after-free of the struct
    file).
    
    The bug was introduced by commit 90ed52e ("[PATCH] holepunch: fix
    mmap_sem i_mutex deadlock")
    
    [bwh: Backported to 3.2:
     - Adjust context
     - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
    [luto: Backported to 3.0: Adjust context]
    
    Cc: Hugh Dickins <hugh@veritas.com>
    Cc: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Badari Pulavarty <pbadari@us.ibm.com>
    Cc: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    amluto committed with gregkh Jul 5, 2012
  5. fs: ramfs: file-nommu: add SetPageUptodate()

    commit fea9f71 upstream.
    
    There is a bug in the below scenario for !CONFIG_MMU:
    
     1. create a new file
     2. mmap the file and write to it
     3. read the file can't get the correct value
    
    Because
    
      sys_read() -> generic_file_aio_read() -> simple_readpage() -> clear_page()
    
    which causes the page to be zeroed.
    
    Add SetPageUptodate() to ramfs_nommu_expand_for_mapping() so that
    generic_file_aio_read() do not call simple_readpage().
    
    Signed-off-by: Bob Liu <lliubbo@gmail.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Greg Ungerer <gerg@uclinux.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>
    lliubbo committed with gregkh Jul 11, 2012
  6. mm, thp: abort compaction if migration page cannot be charged to memcg

    commit 4bf2bba upstream.
    
    If page migration cannot charge the temporary page to the memcg,
    migrate_pages() will return -ENOMEM.  This isn't considered in memory
    compaction however, and the loop continues to iterate over all
    pageblocks trying to isolate and migrate pages.  If a small number of
    very large memcgs happen to be oom, however, these attempts will mostly
    be futile leading to an enormous amout of cpu consumption due to the
    page migration failures.
    
    This patch will short circuit and fail memory compaction if
    migrate_pages() returns -ENOMEM.  COMPACT_PARTIAL is returned in case
    some migrations were successful so that the page allocator will retry.
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.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@linuxfoundation.org>
    David Rientjes committed with gregkh Jul 11, 2012
  7. drivers/rtc/rtc-mxc.c: fix irq enabled interrupts warning

    commit b59f6d1 upstream.
    
    Fixes
    
      WARNING: at irq/handle.c:146 handle_irq_event_percpu+0x19c/0x1b8()
      irq 25 handler mxc_rtc_interrupt+0x0/0xac enabled interrupts
      Modules linked in:
       (unwind_backtrace+0x0/0xf0) from (warn_slowpath_common+0x4c/0x64)
       (warn_slowpath_common+0x4c/0x64) from (warn_slowpath_fmt+0x30/0x40)
       (warn_slowpath_fmt+0x30/0x40) from (handle_irq_event_percpu+0x19c/0x1b8)
       (handle_irq_event_percpu+0x19c/0x1b8) from (handle_irq_event+0x28/0x38)
       (handle_irq_event+0x28/0x38) from (handle_level_irq+0x80/0xc4)
       (handle_level_irq+0x80/0xc4) from (generic_handle_irq+0x24/0x38)
       (generic_handle_irq+0x24/0x38) from (handle_IRQ+0x30/0x84)
       (handle_IRQ+0x30/0x84) from (avic_handle_irq+0x2c/0x4c)
       (avic_handle_irq+0x2c/0x4c) from (__irq_svc+0x40/0x60)
      Exception stack(0xc050bf60 to 0xc050bfa8)
      bf60: 00000001 00000000 003c4208 c0018e20 c050a000 c050a000 c054a4c8 c050a000
      bf80: c05157a8 4117b363 80503bb4 00000000 01000000 c050bfa8 c0018e2c c000e808
      bfa0: 60000013 ffffffff
       (__irq_svc+0x40/0x60) from (default_idle+0x1c/0x30)
       (default_idle+0x1c/0x30) from (cpu_idle+0x68/0xa8)
       (cpu_idle+0x68/0xa8) from (start_kernel+0x22c/0x26c)
    
    Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Cc: Sascha Hauer <kernel@pengutronix.de>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    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>
    bthebaudeau committed with gregkh Jul 11, 2012
  8. memory hotplug: fix invalid memory access caused by stale kswapd pointer

    commit d8adde1 upstream.
    
    kswapd_stop() is called to destroy the kswapd work thread when all memory
    of a NUMA node has been offlined.  But kswapd_stop() only terminates the
    work thread without resetting NODE_DATA(nid)->kswapd to NULL.  The stale
    pointer will prevent kswapd_run() from creating a new work thread when
    adding memory to the memory-less NUMA node again.  Eventually the stale
    pointer may cause invalid memory access.
    
    An example stack dump as below. It's reproduced with 2.6.32, but latest
    kernel has the same issue.
    
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<ffffffff81051a94>] exit_creds+0x12/0x78
      PGD 0
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/devices/system/memory/memory391/state
      CPU 11
      Modules linked in: cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq microcode fuse loop dm_mod tpm_tis rtc_cmos i2c_i801 rtc_core tpm serio_raw pcspkr sg tpm_bios igb i2c_core iTCO_wdt rtc_lib mptctl iTCO_vendor_support button dca bnx2 usbhid hid uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif edd ext3 mbcache jbd fan ide_pci_generic ide_core ata_generic ata_piix libata thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas scsi_mod
      Pid: 7949, comm: sh Not tainted 2.6.32.12-qiuxishi-5-default #92 Tecal RH2285
      RIP: 0010:exit_creds+0x12/0x78
      RSP: 0018:ffff8806044f1d78  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffff880604f22140 RCX: 0000000000019502
      RDX: 0000000000000000 RSI: 0000000000000202 RDI: 0000000000000000
      RBP: ffff880604f22150 R08: 0000000000000000 R09: ffffffff81a4dc10
      R10: 00000000000032a0 R11: ffff880006202500 R12: 0000000000000000
      R13: 0000000000c40000 R14: 0000000000008000 R15: 0000000000000001
      FS:  00007fbc03d066f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 000000060f029000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process sh (pid: 7949, threadinfo ffff8806044f0000, task ffff880603d7c600)
      Stack:
       ffff880604f22140 ffffffff8103aac5 ffff880604f22140 ffffffff8104d21e
       ffff880006202500 0000000000008000 0000000000c38000 ffffffff810bd5b1
       0000000000000000 ffff880603d7c600 00000000ffffdd29 0000000000000003
      Call Trace:
        __put_task_struct+0x5d/0x97
        kthread_stop+0x50/0x58
        offline_pages+0x324/0x3da
        memory_block_change_state+0x179/0x1db
        store_mem_state+0x9e/0xbb
        sysfs_write_file+0xd0/0x107
        vfs_write+0xad/0x169
        sys_write+0x45/0x6e
        system_call_fastpath+0x16/0x1b
      Code: ff 4d 00 0f 94 c0 84 c0 74 08 48 89 ef e8 1f fd ff ff 5b 5d 31 c0 41 5c c3 53 48 8b 87 20 06 00 00 48 89 fb 48 8b bf 18 06 00 00 <8b> 00 48 c7 83 18 06 00 00 00 00 00 00 f0 ff 0f 0f 94 c0 84 c0
      RIP  exit_creds+0x12/0x78
       RSP <ffff8806044f1d78>
      CR2: 0000000000000000
    
    [akpm@linux-foundation.org: add pglist_data.kswapd locking comments]
    Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Acked-by: David Rientjes <rientjes@google.com>
    Reviewed-by: Minchan Kim <minchan@kernel.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>
    Jiang Liu committed with gregkh Jul 11, 2012
  9. md/raid10: Don't try to recovery unmatched (and unused) chunks.

    commit fc448a1 upstream.
    
    If a RAID10 has an odd number of chunks - as might happen when there
    are an odd number of devices - the last chunk has no pair and so is
    not mirrored.  We don't store data there, but when recovering the last
    device in an array we retry to recover that last chunk from a
    non-existent location.  This results in an error, and the recovery
    aborts.
    
    When we get to that last chunk we should just stop - there is nothing
    more to do anyway.
    
    This bug has been present since the introduction of RAID10, so the
    patch is appropriate for any -stable kernel.
    
    Reported-by: Christian Balzer <chibi@gol.com>
    Tested-by: Christian Balzer <chibi@gol.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    neilbrown committed with gregkh Jul 3, 2012
  10. md/raid5: Do not add data_offset before call to is_badblock

    commit 6c0544e upstream.
    
    In chunk_aligned_read() we are adding data_offset before calling
    is_badblock.  But is_badblock also adds data_offset, so that is bad.
    
    So move the addition of data_offset to after the call to
    is_badblock.
    
    This bug was introduced by commit 31c176e
         md/raid5: avoid reading from known bad blocks.
    which first appeared in 3.0.  So that patch is suitable for any
    -stable kernel from 3.0.y onwards.  However it will need minor
    revision for most of those (as the comment didn't appear until
    recently).
    
    Signed-off-by: majianpeng <majianpeng@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    [bwh: Backported to 3.2: ignored missing comment]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    majianpeng committed with gregkh Jun 12, 2012
  11. x86, cpufeature: Rename X86_FEATURE_DTS to X86_FEATURE_DTHERM

    commit 4ad3341 upstream.
    
    It makes sense to label "Digital Thermal Sensor" as "DTS", but
    unfortunately the string "dts" was already used for "Debug Store", and
    /proc/cpuinfo is a user space ABI.
    
    Therefore, rename this to "dtherm".
    
    This conflict went into mainline via the hwmon tree without any x86
    maintainer ack, and without any kind of hint in the subject.
    
        a465905 x86/hwmon: fix initialization of coretemp
    
    Reported-by: Jean Delvare <khali@linux-fr.org>
    Link: http://lkml.kernel.org/r/4FE34BCB.5050305@linux.intel.com
    Cc: Jan Beulich <JBeulich@suse.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    [bwh: Backported to 3.2: drop the coretemp device table change]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    H. Peter Anvin committed with gregkh Jun 22, 2012