1. 30 Oct, 2016 1 commit
  2. 23 Oct, 2016 5 commits
    • Sasha Levin's avatar
      Linux 4.1.35 · 9ca365c0
      Sasha Levin authored
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9ca365c0
    • Mathias Nyman's avatar
      xhci: fix usb2 resume timing and races. · 3b244a6e
      Mathias Nyman authored
      [ Upstream commit f69115fd ]
      
      According to USB 2 specs ports need to signal resume for at least 20ms,
      in practice even longer, before moving to U0 state.
      Both host and devices can initiate resume.
      
      On device initiated resume, a port status interrupt with the port in resume
      state in issued. The interrupt handler tags a resume_done[port]
      timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
      Root hub timer requests for port status, finds the port in resume state,
      checks if resume_done[port] timestamp passed, and set port to U0 state.
      
      On host initiated resume, current code sets the port to resume state,
      sleep 20ms, and finally sets the port to U0 state. This should also
      be changed to work in a similar way as the device initiated resume, with
      timestamp tagging, but that is not yet tested and will be a separate
      fix later.
      
      There are a few issues with this approach
      
      1. A host initiated resume will also generate a resume event. The event
         handler will find the port in resume state, believe it's a device
         initiated resume, and act accordingly.
      
      2. A port status request might cut the resume signalling short if a
         get_port_status request is handled during the host resume signalling.
         The port will be found in resume state. The timestamp is not set leading
         to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
         get_port_status will proceed with moving the port to U0.
      
      3. If an error, or anything else happens to the port during device
         initiated resume signalling it will leave all the device resume
         parameters hanging uncleared, preventing further suspend, returning
         -EBUSY, and cause the pm thread to busyloop trying to enter suspend.
      
      Fix this by using the existing resuming_ports bitfield to indicate that
      resume signalling timing is taken care of.
      Check if the resume_done[port] is set before using it for timestamp
      comparison, and also clear out any resume signalling related variables
      if port is not in U0 or Resume state
      
      This issue was discovered when a PM thread busylooped, trying to runtime
      suspend the xhci USB 2 roothub on a Dell XPS
      
      Cc: stable <stable@vger.kernel.org>
      Reported-by: default avatarDaniel J Blueman <daniel@quora.org>
      Tested-by: default avatarDaniel J Blueman <daniel@quora.org>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3b244a6e
    • Linus Torvalds's avatar
      mm: remove gup_flags FOLL_WRITE games from __get_user_pages() · c865f98d
      Linus Torvalds authored
      [ Upstream commit 19be0eaf ]
      
      This is an ancient bug that was actually attempted to be fixed once
      (badly) by me eleven years ago in commit 4ceb5db9 ("Fix
      get_user_pages() race for write access") but that was then undone due to
      problems on s390 by commit f33ea7f4 ("fix get_user_pages bug").
      
      In the meantime, the s390 situation has long been fixed, and we can now
      fix it by checking the pte_dirty() bit properly (and do it better).  The
      s390 dirty bit was implemented in abf09bed ("s390/mm: implement
      software dirty bits") which made it into v3.9.  Earlier kernels will
      have to look at the page state itself.
      
      Also, the VM has become more scalable, and what used a purely
      theoretical race back then has become easier to trigger.
      
      To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
      we already did a COW" rather than play racy games with FOLL_WRITE that
      is very fundamental, and then use the pte dirty flag to validate that
      the FOLL_COW flag is still valid.
      Reported-and-tested-by: default avatarPhil "not Paul" Oester <kernel@linuxace.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Nick Piggin <npiggin@gmail.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c865f98d
    • John Stultz's avatar
      timekeeping: Fix __ktime_get_fast_ns() regression · 4edf04a3
      John Stultz authored
      [ Upstream commit 58bfea95 ]
      
      In commit 27727df2 ("Avoid taking lock in NMI path with
      CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code
      the timekeeping_get_ns() function, but I forgot to include
      the unit conversion from cycles to nanoseconds, breaking the
      function's output, which impacts users like perf.
      
      This results in bogus perf timestamps like:
       swapper     0 [000]   253.427536:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.426573:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.426687:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.426800:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.426905:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.427022:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.427127:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.427239:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.427346:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   254.427463:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]   255.426572:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
      
      Instead of more reasonable expected timestamps like:
       swapper     0 [000]    39.953768:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.064839:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.175956:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.287103:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.398217:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.509324:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.620437:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.731546:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.842654:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    40.953772:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
       swapper     0 [000]    41.064881:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
      
      Add the proper use of timekeeping_delta_to_ns() to convert
      the cycle delta to nanoseconds as needed.
      
      Thanks to Brendan and Alexei for finding this quickly after
      the v4.8 release. Unfortunately the problematic commit has
      landed in some -stable trees so they'll need this fix as
      well.
      
      Many apologies for this mistake. I'll be looking to add a
      perf-clock sanity test to the kselftest timers tests soon.
      
      Fixes: 27727df2 "timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING"
      Reported-by: default avatarBrendan Gregg <bgregg@netflix.com>
      Reported-by: default avatarAlexei Starovoitov <alexei.starovoitov@gmail.com>
      Tested-and-reviewed-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable <stable@vger.kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1475636148-26539-1-git-send-email-john.stultz@linaro.orgSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      4edf04a3
    • Christopher S. Hall's avatar
      time: Add cycles to nanoseconds translation · 486eeb6d
      Christopher S. Hall authored
      [ Upstream commit 6bd58f09 ]
      
      The timekeeping code does not currently provide a way to translate
      externally provided clocksource cycles to system time. The cycle count
      is always provided by the result clocksource read() method internal to
      the timekeeping code. The added function timekeeping_cycles_to_ns()
      calculated a nanosecond value from a cycle count that can be added to
      tk_read_base.base value yielding the current system time. This allows
      clocksource cycle values external to the timekeeping code to provide a
      cycle count that can be transformed to system time.
      
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: kevin.b.stanton@intel.com
      Cc: kevin.j.clarke@intel.com
      Cc: hpa@zytor.com
      Cc: jeffrey.t.kirsher@intel.com
      Cc: netdev@vger.kernel.org
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarChristopher S. Hall <christopher.s.hall@intel.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      486eeb6d
  3. 10 Oct, 2016 3 commits
  4. 04 Oct, 2016 5 commits
    • Al Viro's avatar
      fix memory leaks in tracing_buffers_splice_read() · e22ff454
      Al Viro authored
      [ Upstream commit 1ae2293d ]
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e22ff454
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Move mutex to protect against resetting of seq data · abd91e8b
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 1245800c ]
      
      The iter->seq can be reset outside the protection of the mutex. So can
      reading of user data. Move the mutex up to the beginning of the function.
      
      Fixes: d7350c3f ("tracing/core: make the read callbacks reentrants")
      Cc: stable@vger.kernel.org # 2.6.30+
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      abd91e8b
    • Matt Redfearn's avatar
      MIPS: SMP: Fix possibility of deadlock when bringing CPUs online · 7d0e5777
      Matt Redfearn authored
      [ Upstream commit 8f46cca1 ]
      
      This patch fixes the possibility of a deadlock when bringing up
      secondary CPUs.
      The deadlock occurs because the set_cpu_online() is called before
      synchronise_count_slave(). This can cause a deadlock if the boot CPU,
      having scheduled another thread, attempts to send an IPI to the
      secondary CPU, which it sees has been marked online. The secondary is
      blocked in synchronise_count_slave() waiting for the boot CPU to enter
      synchronise_count_master(), but the boot cpu is blocked in
      smp_call_function_many() waiting for the secondary to respond to it's
      IPI request.
      
      Fix this by marking the CPU online in cpu_callin_map and synchronising
      counters before declaring the CPU online and calculating the maps for
      IPIs.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Reported-by: default avatarJustin Chen <justinpopo6@gmail.com>
      Tested-by: default avatarJustin Chen <justinpopo6@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: stable@vger.kernel.org # v4.1+
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14302/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7d0e5777
    • Paul Burton's avatar
      MIPS: Fix pre-r6 emulation FPU initialisation · 94b73f6d
      Paul Burton authored
      [ Upstream commit 7e956304 ]
      
      In the mipsr2_decoder() function, used to emulate pre-MIPSr6
      instructions that were removed in MIPSr6, the init_fpu() function is
      called if a removed pre-MIPSr6 floating point instruction is the first
      floating point instruction used by the task. However, init_fpu()
      performs varous actions that rely upon not being migrated. For example
      in the most basic case it sets the coprocessor 0 Status.CU1 bit to
      enable the FPU & then loads FP register context into the FPU registers.
      If the task were to migrate during this time, it may end up attempting
      to load FP register context on a different CPU where it hasn't set the
      CU1 bit, leading to errors such as:
      
          do_cpu invoked from kernel context![#2]:
          CPU: 2 PID: 7338 Comm: fp-prctl Tainted: G      D         4.7.0-00424-g49b0c82 #2
          task: 838e4000 ti: 88d38000 task.ti: 88d38000
          $ 0   : 00000000 00000001 ffffffff 88d3fef8
          $ 4   : 838e4000 88d38004 00000000 00000001
          $ 8   : 3400fc01 801f8020 808e9100 24000000
          $12   : dbffffff 807b69d8 807b0000 00000000
          $16   : 00000000 80786150 00400fc4 809c0398
          $20   : 809c0338 0040273c 88d3ff28 808e9d30
          $24   : 808e9d30 00400fb4
          $28   : 88d38000 88d3fe88 00000000 8011a2ac
          Hi    : 0040273c
          Lo    : 88d3ff28
          epc   : 80114178 _restore_fp+0x10/0xa0
          ra    : 8011a2ac mipsr2_decoder+0xd5c/0x1660
          Status: 1400fc03	KERNEL EXL IE
          Cause : 1080002c (ExcCode 0b)
          PrId  : 0001a920 (MIPS I6400)
          Modules linked in:
          Process fp-prctl (pid: 7338, threadinfo=88d38000, task=838e4000, tls=766527d0)
          Stack : 00000000 00000000 00000000 88d3fe98 00000000 00000000 809c0398 809c0338
          	  808e9100 00000000 88d3ff28 00400fc4 00400fc4 0040273c 7fb69e18 004a0000
          	  004a0000 004a0000 7664add0 8010de18 00000000 00000000 88d3fef8 88d3ff28
          	  808e9100 00000000 766527d0 8010e534 000c0000 85755000 8181d580 00000000
          	  00000000 00000000 004a0000 00000000 766527d0 7fb69e18 004a0000 80105c20
          	  ...
          Call Trace:
          [<80114178>] _restore_fp+0x10/0xa0
          [<8011a2ac>] mipsr2_decoder+0xd5c/0x1660
          [<8010de18>] do_ri+0x90/0x6b8
          [<80105c20>] ret_from_exception+0x0/0x10
      
      Fix this by disabling preemption around the call to init_fpu(), ensuring
      that it starts & completes on one CPU.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Fixes: b0a668fb ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for MIPS R6")
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # v4.0+
      Patchwork: https://patchwork.linux-mips.org/patch/14305/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      94b73f6d
    • Jeff Mahoney's avatar
      btrfs: ensure that file descriptor used with subvol ioctls is a dir · 3b3f2e91
      Jeff Mahoney authored
      [ Upstream commit 325c50e3 ]
      
      If the subvol/snapshot create/destroy ioctls are passed a regular file
      with execute permissions set, we'll eventually Oops while trying to do
      inode->i_op->lookup via lookup_one_len.
      
      This patch ensures that the file descriptor refers to a directory.
      
      Fixes: cb8e7090 (Btrfs: Fix subvolume creation locking rules)
      Fixes: 76dda93c (Btrfs: add snapshot/subvolume destroy ioctl)
      Cc: <stable@vger.kernel.org> #v2.6.29+
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3b3f2e91
  5. 03 Oct, 2016 26 commits