1. 09 Mar, 2016 15 commits
    • Takashi Iwai's avatar
      ALSA: hda - Loop interrupt handling until really cleared · 8e93853b
      Takashi Iwai authored
      commit 473f4145 upstream.
      
      Currently the interrupt handler of HD-audio driver assumes that no irq
      update is needed while processing the irq.  But in reality, it has
      been confirmed that the HW irq is issued even during the irq
      handling.  Since we clear the irq status at the beginning, process the
      interrupt, then exits from the handler, the lately issued interrupt is
      left untouched without being properly processed.
      
      This patch changes the interrupt handler code to loop over the
      check-and-process.  The handler tries repeatedly as long as the IRQ
      status are turned on, and either stream or CORB/RIRB is handled.
      
      For checking the stream handling, snd_hdac_bus_handle_stream_irq()
      returns a value indicating the stream indices bits.  Other than that,
      the change is only in the irq handler itself.
      Reported-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ kamal: backport to 4.2-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8e93853b
    • Takashi Iwai's avatar
      ALSA: hda - Fix headset support and noise on HP EliteBook 755 G2 · 073bcb74
      Takashi Iwai authored
      commit f883982d upstream.
      
      HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires
      the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic
      working.  Also, it suffers from the loopback noise problem, so we
      should disable aamix path as well.
      Reported-by: default avatarDerick Eddington <derick.eddington@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      073bcb74
    • David Henningsson's avatar
      ALSA: hda - Fixup speaker pass-through control for nid 0x14 on ALC225 · 5f383b74
      David Henningsson authored
      commit 2ae95577 upstream.
      
      On one of the machines we enable, we found that the actual speaker volume
      did not always correspond to the volume set in alsamixer. This patch
      fixes that problem.
      
      This patch was orginally written by Kailang @ Realtek, I've rebased it
      to fit sound git master.
      
      BugLink: https://bugs.launchpad.net/bugs/1549660Co-Authored-By: default avatarKailang <kailang@realtek.com>
      Signed-off-by: default avatarDavid Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5f383b74
    • Kailang Yang's avatar
      ALSA: hda/realtek - Support Dell headset mode for ALC225 · cfaec529
      Kailang Yang authored
      commit cfc5a845 upstream.
      
      Dell create new platform with ALC298 codec.
      This patch will enable headset mode for ALC225/ALC3253 platform.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cfaec529
    • Mike Krinkin's avatar
      KVM: x86: MMU: fix ubsan index-out-of-range warning · 49fbf823
      Mike Krinkin authored
      commit 17e4bce0 upstream.
      
      Ubsan reports the following warning due to a typo in
      update_accessed_dirty_bits template, the patch fixes
      the typo:
      
      [  168.791851] ================================================================================
      [  168.791862] UBSAN: Undefined behaviour in arch/x86/kvm/paging_tmpl.h:252:15
      [  168.791866] index 4 is out of range for type 'u64 [4]'
      [  168.791871] CPU: 0 PID: 2950 Comm: qemu-system-x86 Tainted: G           O L  4.5.0-rc5-next-20160222 #7
      [  168.791873] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
      [  168.791876]  0000000000000000 ffff8801cfcaf208 ffffffff81c9f780 0000000041b58ab3
      [  168.791882]  ffffffff82eb2cc1 ffffffff81c9f6b4 ffff8801cfcaf230 ffff8801cfcaf1e0
      [  168.791886]  0000000000000004 0000000000000001 0000000000000000 ffffffffa1981600
      [  168.791891] Call Trace:
      [  168.791899]  [<ffffffff81c9f780>] dump_stack+0xcc/0x12c
      [  168.791904]  [<ffffffff81c9f6b4>] ? _atomic_dec_and_lock+0xc4/0xc4
      [  168.791910]  [<ffffffff81da9e81>] ubsan_epilogue+0xd/0x8a
      [  168.791914]  [<ffffffff81daafa2>] __ubsan_handle_out_of_bounds+0x15c/0x1a3
      [  168.791918]  [<ffffffff81daae46>] ? __ubsan_handle_shift_out_of_bounds+0x2bd/0x2bd
      [  168.791922]  [<ffffffff811287ef>] ? get_user_pages_fast+0x2bf/0x360
      [  168.791954]  [<ffffffffa1794050>] ? kvm_largepages_enabled+0x30/0x30 [kvm]
      [  168.791958]  [<ffffffff81128530>] ? __get_user_pages_fast+0x360/0x360
      [  168.791987]  [<ffffffffa181b818>] paging64_walk_addr_generic+0x1b28/0x2600 [kvm]
      [  168.792014]  [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
      [  168.792019]  [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
      [  168.792044]  [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
      [  168.792076]  [<ffffffffa181c36d>] paging64_gva_to_gpa+0x7d/0x110 [kvm]
      [  168.792121]  [<ffffffffa181c2f0>] ? paging64_walk_addr_generic+0x2600/0x2600 [kvm]
      [  168.792130]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
      [  168.792178]  [<ffffffffa17d9a4a>] emulator_read_write_onepage+0x27a/0x1150 [kvm]
      [  168.792208]  [<ffffffffa1794d44>] ? __kvm_read_guest_page+0x54/0x70 [kvm]
      [  168.792234]  [<ffffffffa17d97d0>] ? kvm_task_switch+0x160/0x160 [kvm]
      [  168.792238]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
      [  168.792263]  [<ffffffffa17daa07>] emulator_read_write+0xe7/0x6d0 [kvm]
      [  168.792290]  [<ffffffffa183b620>] ? em_cr_write+0x230/0x230 [kvm]
      [  168.792314]  [<ffffffffa17db005>] emulator_write_emulated+0x15/0x20 [kvm]
      [  168.792340]  [<ffffffffa18465f8>] segmented_write+0xf8/0x130 [kvm]
      [  168.792367]  [<ffffffffa1846500>] ? em_lgdt+0x20/0x20 [kvm]
      [  168.792374]  [<ffffffffa14db512>] ? vmx_read_guest_seg_ar+0x42/0x1e0 [kvm_intel]
      [  168.792400]  [<ffffffffa1846d82>] writeback+0x3f2/0x700 [kvm]
      [  168.792424]  [<ffffffffa1846990>] ? em_sidt+0xa0/0xa0 [kvm]
      [  168.792449]  [<ffffffffa185554d>] ? x86_decode_insn+0x1b3d/0x4f70 [kvm]
      [  168.792474]  [<ffffffffa1859032>] x86_emulate_insn+0x572/0x3010 [kvm]
      [  168.792499]  [<ffffffffa17e71dd>] x86_emulate_instruction+0x3bd/0x2110 [kvm]
      [  168.792524]  [<ffffffffa17e6e20>] ? reexecute_instruction.part.110+0x2e0/0x2e0 [kvm]
      [  168.792532]  [<ffffffffa14e9a81>] handle_ept_misconfig+0x61/0x460 [kvm_intel]
      [  168.792539]  [<ffffffffa14e9a20>] ? handle_pause+0x450/0x450 [kvm_intel]
      [  168.792546]  [<ffffffffa15130ea>] vmx_handle_exit+0xd6a/0x1ad0 [kvm_intel]
      [  168.792572]  [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
      [  168.792597]  [<ffffffffa17f6bcd>] kvm_arch_vcpu_ioctl_run+0xd3d/0x6090 [kvm]
      [  168.792621]  [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
      [  168.792627]  [<ffffffff8293b530>] ? __ww_mutex_lock_interruptible+0x1630/0x1630
      [  168.792651]  [<ffffffffa17f5e90>] ? kvm_arch_vcpu_runnable+0x4f0/0x4f0 [kvm]
      [  168.792656]  [<ffffffff811eeb30>] ? preempt_notifier_unregister+0x190/0x190
      [  168.792681]  [<ffffffffa17e0447>] ? kvm_arch_vcpu_load+0x127/0x650 [kvm]
      [  168.792704]  [<ffffffffa178e9a3>] kvm_vcpu_ioctl+0x553/0xda0 [kvm]
      [  168.792727]  [<ffffffffa178e450>] ? vcpu_put+0x40/0x40 [kvm]
      [  168.792732]  [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
      [  168.792735]  [<ffffffff82946087>] ? _raw_spin_unlock+0x27/0x40
      [  168.792740]  [<ffffffff8163a943>] ? handle_mm_fault+0x1673/0x2e40
      [  168.792744]  [<ffffffff8129daa8>] ? trace_hardirqs_on_caller+0x478/0x6c0
      [  168.792747]  [<ffffffff8129dcfd>] ? trace_hardirqs_on+0xd/0x10
      [  168.792751]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
      [  168.792756]  [<ffffffff81725a80>] do_vfs_ioctl+0x1b0/0x12b0
      [  168.792759]  [<ffffffff817258d0>] ? ioctl_preallocate+0x210/0x210
      [  168.792763]  [<ffffffff8174aef3>] ? __fget+0x273/0x4a0
      [  168.792766]  [<ffffffff8174acd0>] ? __fget+0x50/0x4a0
      [  168.792770]  [<ffffffff8174b1f6>] ? __fget_light+0x96/0x2b0
      [  168.792773]  [<ffffffff81726bf9>] SyS_ioctl+0x79/0x90
      [  168.792777]  [<ffffffff82946880>] entry_SYSCALL_64_fastpath+0x23/0xc1
      [  168.792780] ================================================================================
      Signed-off-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Reviewed-by: default avatarXiao Guangrong <guangrong.xiao@linux.intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      49fbf823
    • Kai-Heng Feng's avatar
      ALSA: hda - Fixing background noise on Dell Inspiron 3162 · 2bfc02f6
      Kai-Heng Feng authored
      commit 3b43b71f upstream.
      
      After login to the desktop on Dell Inspiron 3162,
      there's a very loud background noise comes from the builtin speaker.
      The noise does not go away even if the speaker is muted.
      
      The noise disappears after using the aamix fixup.
      
      Codec: Realtek ALC3234
      Address: 0
      AFG Function Id: 0x1 (unsol 1)
          Vendor Id: 0x10ec0255
          Subsystem Id: 0x10280725
          Revision Id: 0x100002
          No Modem Function Group found
      
      BugLink: http://bugs.launchpad.net/bugs/1549620Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2bfc02f6
    • Ilya Dryomov's avatar
      libceph: use the right footer size when skipping a message · 2cb494b7
      Ilya Dryomov authored
      commit dbc0d3ca upstream.
      
      ceph_msg_footer is 21 bytes long, while ceph_msg_footer_old is only 13.
      Don't skip too much when CEPH_FEATURE_MSG_AUTH isn't negotiated.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2cb494b7
    • Ilya Dryomov's avatar
      libceph: don't bail early from try_read() when skipping a message · 1b04601d
      Ilya Dryomov authored
      commit e7a88e82 upstream.
      
      The contract between try_read() and try_write() is that when called
      each processes as much data as possible.  When instructed by osd_client
      to skip a message, try_read() is violating this contract by returning
      after receiving and discarding a single message instead of checking for
      more.  try_write() then gets a chance to write out more requests,
      generating more replies/skips for try_read() to handle, forcing the
      messenger into a starvation loop.
      Reported-by: default avatarVarada Kari <Varada.Kari@sandisk.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Tested-by: default avatarVarada Kari <Varada.Kari@sandisk.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1b04601d
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix showing function event in available_events · 4ee13d45
      Steven Rostedt (Red Hat) authored
      commit d045437a upstream.
      
      The ftrace:function event is only displayed for parsing the function tracer
      data. It is not used to enable function tracing, and does not include an
      "enable" file in its event directory.
      
      Originally, this event was kept separate from other events because it did
      not have a ->reg parameter. But perf added a "reg" parameter for its use
      which caused issues, because it made the event available to functions where
      it was not compatible for.
      
      Commit 9b63776f "tracing: Do not enable function event with enable"
      added a TRACE_EVENT_FL_IGNORE_ENABLE flag that prevented the function event
      from being enabled by normal trace events. But this commit missed keeping
      the function event from being displayed by the "available_events" directory,
      which is used to show what events can be enabled by set_event.
      
      One documented way to enable all events is to:
      
       cat available_events > set_event
      
      But because the function event is displayed in the available_events, this
      now causes an INVALID error:
      
       cat: write error: Invalid argument
      Reported-by: default avatarChunyu Hu <chuhu@redhat.com>
      Fixes: 9b63776f "tracing: Do not enable function event with enable"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      4ee13d45
    • Christian Borntraeger's avatar
      KVM: async_pf: do not warn on page allocation failures · e01dab7a
      Christian Borntraeger authored
      commit d7444794 upstream.
      
      In async_pf we try to allocate with NOWAIT to get an element quickly
      or fail. This code also handle failures gracefully. Lets silence
      potential page allocation failures under load.
      
      qemu-system-s39: page allocation failure: order:0,mode:0x2200000
      [...]
      Call Trace:
      ([<00000000001146b8>] show_trace+0xf8/0x148)
      [<000000000011476a>] show_stack+0x62/0xe8
      [<00000000004a36b8>] dump_stack+0x70/0x98
      [<0000000000272c3a>] warn_alloc_failed+0xd2/0x148
      [<000000000027709e>] __alloc_pages_nodemask+0x94e/0xb38
      [<00000000002cd36a>] new_slab+0x382/0x400
      [<00000000002cf7ac>] ___slab_alloc.constprop.30+0x2dc/0x378
      [<00000000002d03d0>] kmem_cache_alloc+0x160/0x1d0
      [<0000000000133db4>] kvm_setup_async_pf+0x6c/0x198
      [<000000000013dee8>] kvm_arch_vcpu_ioctl_run+0xd48/0xd58
      [<000000000012fcaa>] kvm_vcpu_ioctl+0x372/0x690
      [<00000000002f66f6>] do_vfs_ioctl+0x3be/0x510
      [<00000000002f68ec>] SyS_ioctl+0xa4/0xb8
      [<0000000000781c5e>] system_call+0xd6/0x264
      [<000003ffa24fa06a>] 0x3ffa24fa06a
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: default avatarDominik Dingel <dingel@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e01dab7a
    • Paolo Bonzini's avatar
      KVM: x86: fix missed hardware breakpoints · 175cbf05
      Paolo Bonzini authored
      commit 172b2386 upstream.
      
      Sometimes when setting a breakpoint a process doesn't stop on it.
      This is because the debug registers are not loaded correctly on
      VCPU load.
      
      The following simple reproducer from Oleg Nesterov tries using debug
      registers in two threads.  To see the bug, run a 2-VCPU guest with
      "taskset -c 0" and run "./bp 0 1" inside the guest.
      
          #include <unistd.h>
          #include <signal.h>
          #include <stdlib.h>
          #include <stdio.h>
          #include <sys/wait.h>
          #include <sys/ptrace.h>
          #include <sys/user.h>
          #include <asm/debugreg.h>
          #include <assert.h>
      
          #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
      
          unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len)
          {
              unsigned long dr7;
      
              dr7 = ((len | type) & 0xf)
                  << (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE);
              if (enable)
                  dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE));
      
              return dr7;
          }
      
          int write_dr(int pid, int dr, unsigned long val)
          {
              return ptrace(PTRACE_POKEUSER, pid,
                      offsetof (struct user, u_debugreg[dr]),
                      val);
          }
      
          void set_bp(pid_t pid, void *addr)
          {
              unsigned long dr7;
              assert(write_dr(pid, 0, (long)addr) == 0);
              dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1);
              assert(write_dr(pid, 7, dr7) == 0);
          }
      
          void *get_rip(int pid)
          {
              return (void*)ptrace(PTRACE_PEEKUSER, pid,
                      offsetof(struct user, regs.rip), 0);
          }
      
          void test(int nr)
          {
              void *bp_addr = &&label + nr, *bp_hit;
              int pid;
      
              printf("test bp %d\n", nr);
              assert(nr < 16); // see 16 asm nops below
      
              pid = fork();
              if (!pid) {
                  assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
                  kill(getpid(), SIGSTOP);
                  for (;;) {
                      label: asm (
                          "nop; nop; nop; nop;"
                          "nop; nop; nop; nop;"
                          "nop; nop; nop; nop;"
                          "nop; nop; nop; nop;"
                      );
                  }
              }
      
              assert(pid == wait(NULL));
              set_bp(pid, bp_addr);
      
              for (;;) {
                  assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0);
                  assert(pid == wait(NULL));
      
                  bp_hit = get_rip(pid);
                  if (bp_hit != bp_addr)
                      fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n",
                          bp_hit - &&label, nr);
              }
          }
      
          int main(int argc, const char *argv[])
          {
              while (--argc) {
                  int nr = atoi(*++argv);
                  if (!fork())
                      test(nr);
              }
      
              while (wait(NULL) > 0)
                  ;
              return 0;
          }
      Suggested-by: default avatarNadav Amit <namit@cs.technion.ac.il>
      Reported-by: default avatarAndrey Wagin <avagin@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      175cbf05
    • Vineet Gupta's avatar
      ARCv2: SMP: Emulate IPI to self using software triggered interrupt · c529c186
      Vineet Gupta authored
      commit bb143f81 upstream.
      
      ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to
      local core. So use core intc capability to trigger software
      interrupt to self, using an unsued IRQ #21.
      
      This showed up as csd deadlock with LTP trace_sched on a dual core
      system. This test acts as scheduler fuzzer, triggering all sorts of
      schedulting activity. Trouble starts with IPI to self, which doesn't get
      delivered (effectively lost due to H/w capability), but the msg intended
      to be sent remain enqueued in per-cpu @ipi_data.
      
      All subsequent IPIs to this core from other cores get elided due to the
      IPI coalescing optimization in ipi_send_msg_one() where a pending msg
      implies an IPI already sent and assumes other core is yet to ack it.
      After the elided IPI, other core simply goes into csd_lock_wait()
      but never comes out as this core never sees the interrupt.
      
      Fixes STAR 9001008624
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c529c186
    • Mark Rutland's avatar
      KVM: arm/arm64: vgic: Ensure bitmaps are long enough · ce77d313
      Mark Rutland authored
      commit 236cf17c upstream.
      
      When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
      bits we need by 8 to figure out how many bytes to allocate. However,
      bitmap elements are always accessed as unsigned longs, and if we didn't
      happen to allocate a size such that size % sizeof(unsigned long) == 0,
      bitmap accesses may go past the end of the allocation.
      
      When using KASAN (which does byte-granular access checks), this results
      in a continuous stream of BUGs whenever these bitmaps are accessed:
      
      =============================================================================
      BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
      INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
      INFO: Object 0xffffffc935769500 @offset=1280 fp=0x          (null)
      
      Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G    B           4.4.0+ #17
      Hardware name: ARM Juno development board (r1) (DT)
      Call trace:
      [<ffffffc00008e770>] dump_backtrace+0x0/0x280
      [<ffffffc00008ea04>] show_stack+0x14/0x20
      [<ffffffc000726360>] dump_stack+0x100/0x188
      [<ffffffc00030d324>] print_trailer+0xfc/0x168
      [<ffffffc000312294>] object_err+0x3c/0x50
      [<ffffffc0003140fc>] kasan_report_error+0x244/0x558
      [<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
      [<ffffffc000745688>] __bitmap_or+0xc0/0xc8
      [<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
      [<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
      [<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
      [<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
      [<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
      [<ffffffc000086cb0>] el0_svc_naked+0x24/0x28
      Memory state around the buggy address:
       ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                         ^
       ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      
      Fix the issue by always allocating a multiple of sizeof(unsigned long),
      as we do elsewhere in the vgic code.
      
      Fixes: c1bfb577 ("arm/arm64: KVM: vgic: switch to dynamic allocation")
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ce77d313
    • Stefan Hajnoczi's avatar
      sunrpc/cache: fix off-by-one in qword_get() · e1b2cd08
      Stefan Hajnoczi authored
      commit b7052cd7 upstream.
      
      The qword_get() function NUL-terminates its output buffer.  If the input
      string is in hex format \xXXXX... and the same length as the output
      buffer, there is an off-by-one:
      
        int qword_get(char **bpp, char *dest, int bufsize)
        {
            ...
            while (len < bufsize) {
                ...
                *dest++ = (h << 4) | l;
                len++;
            }
            ...
            *dest = '\0';
            return len;
        }
      
      This patch ensures the NUL terminator doesn't fall outside the output
      buffer.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e1b2cd08
    • Ivaylo Dimitrov's avatar
      ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption · 01e62edc
      Ivaylo Dimitrov authored
      commit 3f315c5b upstream.
      
      Commit e7b11dc7 ("ARM: OMAP2+: Fix onenand rate detection to avoid
      filesystem corruption") partially fixed onenand configuration when GPMC
      module is reset. Finish the job by also providing the correct values in
      ONENAND_REG_SYS_CFG1 register.
      
      Fixes: e7b11dc7 ("ARM: OMAP2+: Fix onenand rate detection to avoid
      filesystem corruption")
      Signed-off-by: default avatarIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Tested-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      01e62edc
  2. 07 Mar, 2016 25 commits
    • Alex Deucher's avatar
      drm/amdgpu/pm: adjust display configuration after powerstate · 564a440a
      Alex Deucher authored
      commit 8e7cedc6 upstream.
      
      set_power_state defaults to no displays, so we need to update
      the display configuration after setting up the powerstate on the
      first call. In most cases this is not an issue since ends up
      getting called multiple times at any given modeset and the proper
      order is achieved in the display changed handling at the top of
      the function.
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Acked-by: default avatarJordan Lazare <Jordan.Lazare@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      564a440a
    • Martin Schwidefsky's avatar
      s390/compat: correct restore of high gprs on signal return · 9221eb14
      Martin Schwidefsky authored
      commit 342300cc upstream.
      
      git commit 80703617
      "s390: add support for vector extension"
      broke 31-bit compat processes in regard to signal handling.
      
      The restore_sigregs_ext32() function is used to restore the additional
      elements from the user space signal frame. Among the additional elements
      are the upper registers halves for 64-bit register support for 31-bit
      processes. The copy_from_user that is used to retrieve the high-gprs
      array from the user stack uses an incorrect length, 8 bytes instead of
      64 bytes. This causes incorrect upper register halves to get loaded.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9221eb14
    • Mike Snitzer's avatar
      dm: fix dm_rq_target_io leak on faults with .request_fn DM w/ blk-mq paths · 234fc39c
      Mike Snitzer authored
      commit 4328daa2 upstream.
      
      Using request-based DM mpath configured with the following stacking
      (.request_fn DM mpath ontop of scsi-mq paths):
      
      echo Y > /sys/module/scsi_mod/parameters/use_blk_mq
      echo N > /sys/module/dm_mod/parameters/use_blk_mq
      
      'struct dm_rq_target_io' would leak if a request is requeued before a
      blk-mq clone is allocated (or fails to allocate).  free_rq_tio()
      wasn't being called.
      
      kmemleak reported:
      
      unreferenced object 0xffff8800b90b98c0 (size 112):
        comm "kworker/7:1H", pid 5692, jiffies 4295056109 (age 78.589s)
        hex dump (first 32 bytes):
          00 d0 5c 2c 03 88 ff ff 40 00 bf 01 00 c9 ff ff  ..\,....@.......
          e0 d9 b1 34 00 88 ff ff 00 00 00 00 00 00 00 00  ...4............
        backtrace:
          [<ffffffff81672b6e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811dbb63>] kmem_cache_alloc+0xc3/0x1e0
          [<ffffffff8117eae5>] mempool_alloc_slab+0x15/0x20
          [<ffffffff8117ec1e>] mempool_alloc+0x6e/0x170
          [<ffffffffa00029ac>] dm_old_prep_fn+0x3c/0x180 [dm_mod]
          [<ffffffff812fbd78>] blk_peek_request+0x168/0x290
          [<ffffffffa0003e62>] dm_request_fn+0xb2/0x1b0 [dm_mod]
          [<ffffffff812f66e3>] __blk_run_queue+0x33/0x40
          [<ffffffff812f9585>] blk_delay_work+0x25/0x40
          [<ffffffff81096fff>] process_one_work+0x14f/0x3d0
          [<ffffffff81097715>] worker_thread+0x125/0x4b0
          [<ffffffff8109ce88>] kthread+0xd8/0xf0
          [<ffffffff8167cb8f>] ret_from_fork+0x3f/0x70
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      crash> struct -o dm_rq_target_io
      struct dm_rq_target_io {
          ...
      }
      SIZE: 112
      
      Fixes: e5863d9a ("dm: allocate requests in target when stacking on blk-mq devices")
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      234fc39c
    • Gerhard Uttenthaler's avatar
      can: ems_usb: Fix possible tx overflow · 872c3882
      Gerhard Uttenthaler authored
      commit 90cfde46 upstream.
      
      This patch fixes the problem that more CAN messages could be sent to the
      interface as could be send on the CAN bus. This was more likely for slow baud
      rates. The sleeping _start_xmit was woken up in the _write_bulk_callback. Under
      heavy TX load this produced another bulk transfer without checking the
      free_slots variable and hence caused the overflow in the interface.
      Signed-off-by: default avatarGerhard Uttenthaler <uttenthaler@ems-wuensche.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      872c3882
    • Lisa Du's avatar
      drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE · b199c7eb
      Lisa Du authored
      commit 7a64cd88 upstream.
      
      There's one point was missed in the patch commit da49889d ("staging:
      binder: Support concurrent 32 bit and 64 bit processes."). When configure
      BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of
      void * is 64bit on 64bit system. Correct it here.
      Signed-off-by: default avatarLisa Du <cldu@marvell.com>
      Signed-off-by: default avatarNicolas Boichat <drinkcat@chromium.org>
      Fixes: da49889d ("staging: binder: Support concurrent 32 bit and 64 bit processes.")
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b199c7eb
    • Simon Guinot's avatar
      kernel/resource.c: fix muxed resource handling in __request_region() · fa9e7382
      Simon Guinot authored
      commit 59ceeaaf upstream.
      
      In __request_region, if a conflict with a BUSY and MUXED resource is
      detected, then the caller goes to sleep and waits for the resource to be
      released.  A pointer on the conflicting resource is kept.  At wake-up
      this pointer is used as a parent to retry to request the region.
      
      A first problem is that this pointer might well be invalid (if for
      example the conflicting resource have already been freed).  Another
      problem is that the next call to __request_region() fails to detect a
      remaining conflict.  The previously conflicting resource is passed as a
      parameter and __request_region() will look for a conflict among the
      children of this resource and not at the resource itself.  It is likely
      to succeed anyway, even if there is still a conflict.
      
      Instead, the parent of the conflicting resource should be passed to
      __request_region().
      
      As a fix, this patch doesn't update the parent resource pointer in the
      case we have to wait for a muxed region right after.
      Reported-and-tested-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarSimon Guinot <simon.guinot@sequanux.org>
      Tested-by: default avatarVincent Donnefort <vdonnefort@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      fa9e7382
    • Nishanth Menon's avatar
      hwmon: (gpio-fan) Remove un-necessary speed_index lookup for thermal hook · f95af21d
      Nishanth Menon authored
      commit 000e0949 upstream.
      
      Thermal hook gpio_fan_get_cur_state is only interested in knowing
      the current speed index that was setup in the system, this is
      already available as part of fan_data->speed_index which is always
      set by set_fan_speed. Using get_fan_speed_index is useful when we
      have no idea about the fan speed configuration (for example during
      fan_ctrl_init).
      
      When thermal framework invokes
      gpio_fan_get_cur_state=>get_fan_speed_index via gpio_fan_get_cur_state
      especially in a polled configuration for thermal governor, we
      basically hog the i2c interface to the extent that other functions
      fail to get any traffic out :(.
      
      Instead, just provide the last state set in the driver - since the gpio
      fan driver is responsible for the fan state immaterial of override, the
      fan_data->speed_index should accurately reflect the state.
      
      Fixes: b5cf88e4 ("(gpio-fan): Add thermal control hooks")
      Reported-by: default avatarTony Lindgren <tony@atomide.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f95af21d
    • Dan Williams's avatar
      nfit: fix multi-interface dimm handling, acpi6.1 compatibility · c1dbab9e
      Dan Williams authored
      commit 6697b2cf upstream.
      
      ACPI 6.1 clarified that multi-interface dimms require multiple control
      region entries (DCRs) per dimm.  Previously we were assuming that a
      control region is only present when block-data-windows are present.
      This implementation was done with an eye to be compatibility with the
      looser ACPI 6.0 interpretation of this table.
      
      1/ When coalescing the memory device (MEMDEV) tables for a single dimm,
      coalesce on device_handle rather than control region index.
      
      2/ Whenever we disocver a control region with non-zero block windows
      re-scan for block-data-window (BDW) entries.
      
      We may need to revisit this if a DIMM ever implements a format interface
      outside of blk or pmem, but that is not on the foreseeable horizon.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c1dbab9e
    • Jan Kara's avatar
      ext4: fix crashes in dioread_nolock mode · 65bfdcc0
      Jan Kara authored
      commit 74dae427 upstream.
      
      Competing overwrite DIO in dioread_nolock mode will just overwrite
      pointer to io_end in the inode. This may result in data corruption or
      extent conversion happening from IO completion interrupt because we
      don't properly set buffer_defer_completion() when unlocked DIO races
      with locked DIO to unwritten extent.
      
      Since unlocked DIO doesn't need io_end for anything, just avoid
      allocating it and corrupting pointer from inode for locked DIO.
      A cleaner fix would be to avoid these games with io_end pointer from the
      inode but that requires more intrusive changes so we leave that for
      later.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      65bfdcc0
    • Jan Kara's avatar
      ext4: fix bh->b_state corruption · 48402861
      Jan Kara authored
      commit ed8ad838 upstream.
      
      ext4 can update bh->b_state non-atomically in _ext4_get_block() and
      ext4_da_get_block_prep(). Usually this is fine since bh is just a
      temporary storage for mapping information on stack but in some cases it
      can be fully living bh attached to a page. In such case non-atomic
      update of bh->b_state can race with an atomic update which then gets
      lost. Usually when we are mapping bh and thus updating bh->b_state
      non-atomically, nobody else touches the bh and so things work out fine
      but there is one case to especially worry about: ext4_finish_bio() uses
      BH_Uptodate_Lock on the first bh in the page to synchronize handling of
      PageWriteback state. So when blocksize < pagesize, we can be atomically
      modifying bh->b_state of a buffer that actually isn't under IO and thus
      can race e.g. with delalloc trying to map that buffer. The result is
      that we can mistakenly set / clear BH_Uptodate_Lock bit resulting in the
      corruption of PageWriteback state or missed unlock of BH_Uptodate_Lock.
      
      Fix the problem by always updating bh->b_state bits atomically.
      Reported-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      48402861
    • Peter Rosin's avatar
      hwmon: (ads1015) Handle negative conversion values correctly · 360714e2
      Peter Rosin authored
      commit acc14694 upstream.
      
      Make the divisor signed as DIV_ROUND_CLOSEST is undefined for negative
      dividends when the divisor is unsigned.
      Signed-off-by: default avatarPeter Rosin <peda@axentia.se>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      360714e2
    • Kirill A. Shutemov's avatar
      ipc/shm: handle removed segments gracefully in shm_mmap() · b5ec8f58
      Kirill A. Shutemov authored
      commit 1ac0b6de upstream.
      
      remap_file_pages(2) emulation can reach file which represents removed
      IPC ID as long as a memory segment is mapped.  It breaks expectations of
      IPC subsystem.
      
      Test case (rewritten to be more human readable, originally autogenerated
      by syzkaller[1]):
      
      	#define _GNU_SOURCE
      	#include <stdlib.h>
      	#include <sys/ipc.h>
      	#include <sys/mman.h>
      	#include <sys/shm.h>
      
      	#define PAGE_SIZE 4096
      
      	int main()
      	{
      		int id;
      		void *p;
      
      		id = shmget(IPC_PRIVATE, 3 * PAGE_SIZE, 0);
      		p = shmat(id, NULL, 0);
      		shmctl(id, IPC_RMID, NULL);
      		remap_file_pages(p, 3 * PAGE_SIZE, 0, 7, 0);
      
      	        return 0;
      	}
      
      The patch changes shm_mmap() and code around shm_lock() to propagate
      locking error back to caller of shm_mmap().
      
      [1] http://github.com/google/syzkallerSigned-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b5ec8f58
    • Davidlohr Bueso's avatar
      ipc: convert invalid scenarios to use WARN_ON · 8ecff6b0
      Davidlohr Bueso authored
      commit d0edd852 upstream.
      
      Considering Linus' past rants about the (ab)use of BUG in the kernel, I
      took a look at how we deal with such calls in ipc.  Given that any errors
      or corruption in ipc code are most likely contained within the set of
      processes participating in the broken mechanisms, there aren't really many
      strong fatal system failure scenarios that would require a BUG call.
      Also, if something is seriously wrong, ipc might not be the place for such
      a BUG either.
      
      1. For example, recently, a customer hit one of these BUG_ONs in shm
         after failing shm_lock().  A busted ID imho does not merit a BUG_ON,
         and WARN would have been better.
      
      2. MSG_COPY functionality of posix msgrcv(2) for checkpoint/restore.
         I don't see how we can hit this anyway -- at least it should be IS_ERR.
          The 'copy' arg from do_msgrcv is always set by calling prepare_copy()
         first and foremost.  We could also probably drop this check altogether.
          Either way, it does not merit a BUG_ON.
      
      3. No ->fault() callback for the fs getting the corresponding page --
         seems selfish to make the system unusable.
      Signed-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8ecff6b0
    • Kirill A. Shutemov's avatar
      mm: fix regression in remap_file_pages() emulation · 95305547
      Kirill A. Shutemov authored
      commit 48f7df32 upstream.
      
      Grazvydas Ignotas has reported a regression in remap_file_pages()
      emulation.
      
      Testcase:
      	#define _GNU_SOURCE
      	#include <assert.h>
      	#include <stdlib.h>
      	#include <stdio.h>
      	#include <sys/mman.h>
      
      	#define SIZE    (4096 * 3)
      
      	int main(int argc, char **argv)
      	{
      		unsigned long *p;
      		long i;
      
      		p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
      				MAP_SHARED | MAP_ANONYMOUS, -1, 0);
      		if (p == MAP_FAILED) {
      			perror("mmap");
      			return -1;
      		}
      
      		for (i = 0; i < SIZE / 4096; i++)
      			p[i * 4096 / sizeof(*p)] = i;
      
      		if (remap_file_pages(p, 4096, 0, 1, 0)) {
      			perror("remap_file_pages");
      			return -1;
      		}
      
      		if (remap_file_pages(p, 4096 * 2, 0, 1, 0)) {
      			perror("remap_file_pages");
      			return -1;
      		}
      
      		assert(p[0] == 1);
      
      		munmap(p, SIZE);
      
      		return 0;
      	}
      
      The second remap_file_pages() fails with -EINVAL.
      
      The reason is that remap_file_pages() emulation assumes that the target
      vma covers whole area we want to over map.  That assumption is broken by
      first remap_file_pages() call: it split the area into two vma.
      
      The solution is to check next adjacent vmas, if they map the same file
      with the same flags.
      
      Fixes: c8d78c18 ("mm: replace remap_file_pages() syscall with emulation")
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Tested-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      95305547
    • Bjørn Mork's avatar
      USB: option: add "4G LTE usb-modem U901" · 22e878fa
      Bjørn Mork authored
      commit d061c1ca upstream.
      
      Thomas reports:
      
      T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=05c6 ProdID=6001 Rev=00.00
      S:  Manufacturer=USB Modem
      S:  Product=USB Modem
      S:  SerialNumber=1234567890ABCDEF
      C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      Reported-by: default avatarThomas Schäfer <tschaefer@t-online.de>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      22e878fa
    • Ken Lin's avatar
      USB: cp210x: add IDs for GE B650V3 and B850V3 boards · d16f0d84
      Ken Lin authored
      commit 6627ae19 upstream.
      
      Add USB ID for cp2104/5 devices on GE B650v3 and B850v3 boards.
      Signed-off-by: default avatarKen Lin <ken.lin@advantech.com.tw>
      Signed-off-by: default avatarAkshay Bhat <akshay.bhat@timesys.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d16f0d84
    • Andrey Skvortsov's avatar
      USB: option: add support for SIM7100E · 0718f2f0
      Andrey Skvortsov authored
      commit 3158a8d4 upstream.
      
      $ lsusb:
      Bus 001 Device 101: ID 1e0e:9001 Qualcomm / Option
      
      $ usb-devices:
      T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=101 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  2
      P:  Vendor=1e0e ProdID=9001 Rev= 2.32
      S:  Manufacturer=SimTech, Incorporated
      S:  Product=SimTech, Incorporated
      S:  SerialNumber=0123456789ABCDEF
      C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
      
      The last interface (6) is used for Android Composite ADB interface.
      
      Serial port layout:
      0: QCDM/DIAG
      1: NMEA
      2: AT
      3: AT/PPP
      4: audio
      Signed-off-by: default avatarAndrey Skvortsov <andrej.skvortzov@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0718f2f0
    • Takashi Iwai's avatar
      ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream · accfc798
      Takashi Iwai authored
      commit 67ec1072 upstream.
      
      A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice
      in the same code path, e.g. one in snd_pcm_action_nonatomic() and
      another in snd_pcm_stream_lock().  Usually this is OK, but when a
      write lock is issued between these two read locks, the problem
      happens: the write lock is blocked due to the first reade lock, and
      the second read lock is also blocked by the write lock.  This
      eventually deadlocks.
      
      The reason is the way rwsem manages waiters; it's queued like FIFO, so
      even if the writer itself doesn't take the lock yet, it blocks all the
      waiters (including reads) queued after it.
      
      As a workaround, in this patch, we replace the standard down_write()
      with an spinning loop.  This is far from optimal, but it's good
      enough, as the spinning time is supposed to be relatively short for
      normal PCM operations, and the code paths requiring the write lock
      aren't called so often.
      Reported-by: default avatarVinod Koul <vinod.koul@intel.com>
      Tested-by: default avatarRamesh Babu <ramesh.babu@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      accfc798
    • Toshi Kani's avatar
      x86/mm: Fix vmalloc_fault() to handle large pages properly · f2282ee1
      Toshi Kani authored
      commit f4eafd8b upstream.
      
      A kernel page fault oops with the callstack below was observed
      when a read syscall was made to a pmem device after a huge amount
      (>512GB) of vmalloc ranges was allocated by ioremap() on a x86_64
      system:
      
           BUG: unable to handle kernel paging request at ffff880840000ff8
           IP: vmalloc_fault+0x1be/0x300
           PGD c7f03a067 PUD 0
           Oops: 0000 [#1] SM
           Call Trace:
              __do_page_fault+0x285/0x3e0
              do_page_fault+0x2f/0x80
              ? put_prev_entity+0x35/0x7a0
              page_fault+0x28/0x30
              ? memcpy_erms+0x6/0x10
              ? schedule+0x35/0x80
              ? pmem_rw_bytes+0x6a/0x190 [nd_pmem]
              ? schedule_timeout+0x183/0x240
              btt_log_read+0x63/0x140 [nd_btt]
               :
              ? __symbol_put+0x60/0x60
              ? kernel_read+0x50/0x80
              SyS_finit_module+0xb9/0xf0
              entry_SYSCALL_64_fastpath+0x1a/0xa4
      
      Since v4.1, ioremap() supports large page (pud/pmd) mappings in
      x86_64 and PAE.  vmalloc_fault() however assumes that the vmalloc
      range is limited to pte mappings.
      
      vmalloc faults do not normally happen in ioremap'd ranges since
      ioremap() sets up the kernel page tables, which are shared by
      user processes.  pgd_ctor() sets the kernel's PGD entries to
      user's during fork().  When allocation of the vmalloc ranges
      crosses a 512GB boundary, ioremap() allocates a new pud table
      and updates the kernel PGD entry to point it.  If user process's
      PGD entry does not have this update yet, a read/write syscall
      to the range will cause a vmalloc fault, which hits the Oops
      above as it does not handle a large page properly.
      
      Following changes are made to vmalloc_fault().
      
      64-bit:
      
       - No change for the PGD sync operation as it handles large
         pages already.
       - Add pud_huge() and pmd_huge() to the validation code to
         handle large pages.
       - Change pud_page_vaddr() to pud_pfn() since an ioremap range
         is not directly mapped (while the if-statement still works
         with a bogus addr).
       - Change pmd_page() to pmd_pfn() since an ioremap range is not
         backed by struct page (while the if-statement still works
         with a bogus addr).
      
      32-bit:
       - No change for the sync operation since the index3 PGD entry
         covers the entire vmalloc range, which is always valid.
         (A separate change to sync PGD entry is necessary if this
          memory layout is changed regardless of the page size.)
       - Add pmd_huge() to the validation code to handle large pages.
         This is for completeness since vmalloc_fault() won't happen
         in ioremap'd ranges as its PGD entry is always valid.
      Reported-by: default avatarHenning Schild <henning.schild@siemens.com>
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Acked-by: default avatarBorislav Petkov <bp@alien8.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-mm@kvack.org
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/1455758214-24623-1-git-send-email-toshi.kani@hpe.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f2282ee1
    • Benjamin Coddington's avatar
      NFSv4: Fix a dentry leak on alias use · 6efe820a
      Benjamin Coddington authored
      commit d9dfd8d7 upstream.
      
      In the case where d_add_unique() finds an appropriate alias to use it will
      have already incremented the reference count.  An additional dget() to swap
      the open context's dentry is unnecessary and will leak a reference.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Fixes: 275bb307 ("NFSv4: Move dentry instantiation into the NFSv4-...")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      6efe820a
    • Alexey Kardashevskiy's avatar
      powerpc/ioda: Set "read" permission when "write" is set · de999d89
      Alexey Kardashevskiy authored
      commit 6ecad912 upstream.
      
      Quite often drivers set only "write" permission assuming that this
      includes "read" permission as well and this works on plenty of
      platforms. However IODA2 is strict about this and produces an EEH when
      "read" permission is not set and reading happens.
      
      This adds a workaround in the IODA code to always add the "read" bit
      when the "write" bit is set.
      
      Fixes: 10b35b2b ("powerpc/powernv: Do not set "read" flag if direction==DMA_NONE")
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Tested-by: default avatarDouglas Miller <dougmill@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      de999d89
    • John Youn's avatar
      usb: dwc3: Fix assignment of EP transfer resources · 863d9af3
      John Youn authored
      commit c4509601 upstream.
      
      The assignement of EP transfer resources was not handled properly in the
      dwc3 driver. Commit aebda618 ("usb: dwc3: Reset the transfer
      resource index on SET_INTERFACE") previously fixed one aspect of this
      where resources may be exhausted with multiple calls to SET_INTERFACE.
      However, it introduced an issue where composite devices with multiple
      interfaces can be assigned the same transfer resources for different
      endpoints. This patch solves both issues.
      
      The assignment of transfer resources cannot perfectly follow the data
      book due to the fact that the controller driver does not have all
      knowledge of the configuration in advance. It is given this information
      piecemeal by the composite gadget framework after every
      SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
      programming model in this scenario can cause errors. For two reasons:
      
      1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
      SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
      interfaces.
      
      2) The databook does not mention doing more DEPXFERCFG for new endpoint
      on alt setting (8.1.6).
      
      The following simplified method is used instead:
      
      All hardware endpoints can be assigned a transfer resource and this
      setting will stay persistent until either a core reset or hibernation.
      So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
      every hardware endpoint as well. We are guaranteed that there are as
      many transfer resources as endpoints.
      
      This patch triggers off of the calling dwc3_gadget_start_config() for
      EP0-out, which always happens first, and which should only happen in one
      of the above conditions.
      
      Fixes: aebda618 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE")
      Reported-by: default avatarRavi Babu <ravibabu@ti.com>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      863d9af3
    • Toshi Kani's avatar
      x86/uaccess/64: Handle the caching of 4-byte nocache copies properly in __copy_user_nocache() · e1aa4f7f
      Toshi Kani authored
      commit a82eee74 upstream.
      
      Data corruption issues were observed in tests which initiated
      a system crash/reset while accessing BTT devices.  This problem
      is reproducible.
      
      The BTT driver calls pmem_rw_bytes() to update data in pmem
      devices.  This interface calls __copy_user_nocache(), which
      uses non-temporal stores so that the stores to pmem are
      persistent.
      
      __copy_user_nocache() uses non-temporal stores when a request
      size is 8 bytes or larger (and is aligned by 8 bytes).  The
      BTT driver updates the BTT map table, which entry size is
      4 bytes.  Therefore, updates to the map table entries remain
      cached, and are not written to pmem after a crash.
      
      Change __copy_user_nocache() to use non-temporal store when
      a request size is 4 bytes.  The change extends the current
      byte-copy path for a less-than-8-bytes request, and does not
      add any overhead to the regular path.
      Reported-and-tested-by: default avatarMicah Parrish <micah.parrish@hpe.com>
      Reported-and-tested-by: default avatarBrian Boylston <brian.boylston@hpe.com>
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/1455225857-12039-3-git-send-email-toshi.kani@hpe.com
      [ Small readability edits. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e1aa4f7f
    • Toshi Kani's avatar
      x86/uaccess/64: Make the __copy_user_nocache() assembly code more readable · f31380e5
      Toshi Kani authored
      commit ee9737c9 upstream.
      
      Add comments to __copy_user_nocache() to clarify its procedures
      and alignment requirements.
      
      Also change numeric branch target labels to named local labels.
      
      No code changed:
      
       arch/x86/lib/copy_user_64.o:
      
          text    data     bss     dec     hex filename
          1239       0       0    1239     4d7 copy_user_64.o.before
          1239       0       0    1239     4d7 copy_user_64.o.after
      
       md5:
          58bed94c2db98c1ca9a2d46d0680aaae  copy_user_64.o.before.asm
          58bed94c2db98c1ca9a2d46d0680aaae  copy_user_64.o.after.asm
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: brian.boylston@hpe.com
      Cc: dan.j.williams@intel.com
      Cc: linux-nvdimm@lists.01.org
      Cc: micah.parrish@hpe.com
      Cc: ross.zwisler@linux.intel.com
      Cc: vishal.l.verma@intel.com
      Link: http://lkml.kernel.org/r/1455225857-12039-2-git-send-email-toshi.kani@hpe.com
      [ Small readability edits and added object file comparison. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f31380e5
    • Mario Kleiner's avatar
      drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2) · 5e9a7dec
      Mario Kleiner authored
      commit bb74fc1b upstream.
      
      drm_vblank_offdelay can have three different types of values:
      
      < 0 is to be always treated the same as dev->vblank_disable_immediate
      = 0 is to be treated as "never disable vblanks"
      > 0 is to be treated as disable immediate if kms driver wants it
          that way via dev->vblank_disable_immediate. Otherwise it is
          a disable timeout in msecs.
      
      This got broken in Linux 3.18+ for the implementation of
      drm_vblank_on. If the user specified a value of zero which should
      always reenable vblank irqs in this function, a kms driver could
      override the users choice by setting vblank_disable_immediate
      to true. This patch fixes the regression and keeps the user in
      control.
      
      v2: Only reenable vblank if there are clients left or the user
          requested to "never disable vblanks" via offdelay 0. Enabling
          vblanks even in the "delayed disable" case (offdelay > 0) was
          specifically added by Ville in commit cd19e52a
          ("drm: Kick start vblank interrupts at drm_vblank_on()"),
          but after discussion it turns out that this was done by accident.
      
          Citing Ville: "I think it just ended up as a mess due to changing
          some of the semantics of offdelay<0 vs. offdelay==0 vs.
          disable_immediate during the review of the series. So yeah, given
          how drm_vblank_put() works now, I'd just make this check for
          offdelay==0."
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      
      Cc: michel@daenzer.net
      Cc: vbabka@suse.cz
      Cc: ville.syrjala@linux.intel.com
      Cc: daniel.vetter@ffwll.ch
      Cc: dri-devel@lists.freedesktop.org
      Cc: alexander.deucher@amd.com
      Cc: christian.koenig@amd.com
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5e9a7dec