1. 05 Mar, 2015 9 commits
  2. 02 Mar, 2015 1 commit
    • James Hogan's avatar
      KVM: MIPS: Don't leak FPU/DSP to guest · 48f80a96
      James Hogan authored
      [ Upstream commit f798217d ]
      
      The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
      kvm_mips_set_c0_status() on a guest exit, presumably in case there is
      active state that needs saving if pre-emption occurs. However neither of
      these bits are cleared again when returning to the guest.
      
      This effectively gives the guest access to the FPU/DSP hardware after
      the first guest exit even though it is not aware of its presence,
      allowing FP instructions in guest user code to intermittently actually
      execute instead of trapping into the guest OS for emulation. It will
      then read & manipulate the hardware FP registers which technically
      belong to the user process (e.g. QEMU), or are stale from another user
      process. It can also crash the guest OS by causing an FP exception, for
      which a guest exception handler won't have been registered.
      
      First lets save and disable the FPU (and MSA) state with lose_fpu(1)
      before entering the guest. This simplifies the problem, especially for
      when guest FPU/MSA support is added in the future, and prevents FR=1 FPU
      state being live when the FR bit gets cleared for the guest, which
      according to the architecture causes the contents of the FPU and vector
      registers to become UNPREDICTABLE.
      
      We can then safely remove the enabling of the FPU in
      kvm_mips_set_c0_status(), since there should never be any active FPU or
      MSA state to save at pre-emption, which should plug the FPU leak.
      
      DSP state is always live rather than being lazily restored, so for that
      it is simpler to just clear the MX bit again when re-entering the guest.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Sanjay Lal <sanjayl@kymasys.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: kvm@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # v3.10+: 044f0f03: MIPS: KVM: Deliver guest interrupts
      Cc: <stable@vger.kernel.org> # v3.10+: 3ce465e0: MIPS: Export FP functions used by lose_fpu(1) for KVM
      Cc: <stable@vger.kernel.org> # v3.10+
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      48f80a96
  3. 01 Mar, 2015 30 commits
    • Alexey Brodkin's avatar
      ARC: fix page address calculation if PAGE_OFFSET != LINUX_LINK_BASE · 02c76a9a
      Alexey Brodkin authored
      commit 06f34e1c upstream.
      
      We used to calculate page address differently in 2 cases:
      
      1. In virt_to_page(x) we do
       --->8---
       mem_map + (x - CONFIG_LINUX_LINK_BASE) >> PAGE_SHIFT
       --->8---
      
      2. In in pte_page(x) we do
       --->8---
       mem_map + (pte_val(x) - PAGE_OFFSET) >> PAGE_SHIFT
       --->8---
      
      That leads to problems in case PAGE_OFFSET != CONFIG_LINUX_LINK_BASE -
      different pages will be selected depending on where and how we calculate
      page address.
      
      In particular in the STAR 9000853582 when gdb attempted to read memory
      of another process it got improper page in get_user_pages() because this
      is exactly one of the places where we search for a page by pte_page().
      
      The fix is trivial - we need to calculate page address similarly in both
      cases.
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      02c76a9a
    • Jay Lan's avatar
      kdb: fix incorrect counts in KDB summary command output · 980af92d
      Jay Lan authored
      commit 14675592 upstream.
      
      The output of KDB 'summary' command should report MemTotal, MemFree
      and Buffers output in kB. Current codes report in unit of pages.
      
      A define of K(x) as
      is defined in the code, but not used.
      
      This patch would apply the define to convert the values to kB.
      Please include me on Cc on replies. I do not subscribe to linux-kernel.
      Signed-off-by: default avatarJay Lan <jlan@sgi.com>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      980af92d
    • Dmitry Eremin-Solenikov's avatar
      ARM: pxa: add regulator_has_full_constraints to poodle board file · 71d9abaa
      Dmitry Eremin-Solenikov authored
      commit 9bc78f32 upstream.
      
      Add regulator_has_full_constraints() call to poodle board file to let
      regulator core know that we do not have any additional regulators left.
      This lets it substitute unprovided regulators with dummy ones.
      
      This fixes the following warnings that can be seen on poodle if
      regulators are enabled:
      
      ads7846 spi1.0: unable to get regulator: -517
      spi spi1.0: Driver ads7846 requests probe deferral
      wm8731 0-001b: Failed to get supply 'AVDD': -517
      wm8731 0-001b: Failed to request supplies: -517
      wm8731 0-001b: ASoC: failed to probe component -517
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      71d9abaa
    • Dmitry Eremin-Solenikov's avatar
      ARM: pxa: add regulator_has_full_constraints to corgi board file · 2b563e61
      Dmitry Eremin-Solenikov authored
      commit 271e8017 upstream.
      
      Add regulator_has_full_constraints() call to corgi board file to let
      regulator core know that we do not have any additional regulators left.
      This lets it substitute unprovided regulators with dummy ones.
      
      This fixes the following warnings that can be seen on corgi if
      regulators are enabled:
      
      ads7846 spi1.0: unable to get regulator: -517
      spi spi1.0: Driver ads7846 requests probe deferral
      wm8731 0-001b: Failed to get supply 'AVDD': -517
      wm8731 0-001b: Failed to request supplies: -517
      wm8731 0-001b: ASoC: failed to probe component -517
      corgi-audio corgi-audio: ASoC: failed to instantiate card -517
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2b563e61
    • Nicolas Pitre's avatar
      vt: provide notifications on selection changes · 7498a0c8
      Nicolas Pitre authored
      commit 19e3ae6b upstream.
      
      The vcs device's poll/fasync support relies on the vt notifier to signal
      changes to the screen content.  Notifier invocations were missing for
      changes that comes through the selection interface though.  Fix that.
      
      Tested with BRLTTY 5.2.
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Cc: Dave Mielke <dave@mielke.cc>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      7498a0c8
    • Sebastian Andrzej Siewior's avatar
      usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN · 4d1799d6
      Sebastian Andrzej Siewior authored
      commit 5efd2ea8 upstream.
      
      the following error pops up during "testusb -a -t 10"
      | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
      hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
      size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
      hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
      might by identified by buffer_offset() as another buffer. This means the
      buffer which is on a 32 byte boundary will not get freed, instead it
      tries to free another buffer with the error message.
      
      This patch fixes the issue by creating the smallest DMA buffer with the
      size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
      smaller). This might be 32, 64 or even 128 bytes. The next three pools
      will have the size 128, 512 and 2048.
      In case the smallest pool is 128 bytes then we have only three pools
      instead of four (and zero the first entry in the array).
      The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
      2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
      we would end up with 8KiB buffer in case we have 16KiB pages.
      Instead I think it makes sense to have a common size(s) and extend them
      if there is need to.
      There is a BUILD_BUG_ON() now in case someone has a minalign of more than
      128 bytes.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      4d1799d6
    • Alan Stern's avatar
      USB: fix use-after-free bug in usb_hcd_unlink_urb() · 5752d1a5
      Alan Stern authored
      commit c9919790 upstream.
      
      The usb_hcd_unlink_urb() routine in hcd.c contains two possible
      use-after-free errors.  The dev_dbg() statement at the end of the
      routine dereferences urb and urb->dev even though both structures may
      have been deallocated.
      
      This patch fixes the problem by storing urb->dev in a local variable
      (avoiding the dereference of urb) and moving the dev_dbg() up before
      the usb_put_dev() call.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      5752d1a5
    • Lennart Sorensen's avatar
      USB: cp210x: add ID for RUGGEDCOM USB Serial Console · e047f04b
      Lennart Sorensen authored
      commit a6f03312 upstream.
      
      Added the USB serial console device ID for Siemens Ruggedcom devices
      which have a USB port for their serial console.
      Signed-off-by: default avatarLen Sorensen <lsorense@csclub.uwaterloo.ca>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e047f04b
    • Cyrille Pitchen's avatar
      tty/serial: at91: fix error handling in atmel_serial_probe() · 79abbf65
      Cyrille Pitchen authored
      commit 6fbb9bdf upstream.
      
      -EDEFER error wasn't handle properly by atmel_serial_probe().
      As an example, when atmel_serial_probe() is called for the first time, we pass
      the test_and_set_bit() test to check whether the port has already been
      initalized. Then we call atmel_init_port(), which may return -EDEFER, possibly
      returned before by clk_get(). Consequently atmel_serial_probe() used to return
      this error code WITHOUT clearing the port bit in the "atmel_ports_in_use" mask.
      When atmel_serial_probe() was called for the second time, it used to fail on
      the test_and_set_bit() function then returning -EBUSY.
      
      When atmel_serial_probe() fails, this patch make it clear the port bit in the
      "atmel_ports_in_use" mask, if needed, before returning the error code.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      79abbf65
    • Peter Hurley's avatar
      tty: Prevent untrappable signals from malicious program · 09179f19
      Peter Hurley authored
      commit 37480a05 upstream.
      
      Commit 26df6d13 ("tty: Add EXTPROC support for LINEMODE")
      allows a process which has opened a pty master to send _any_ signal
      to the process group of the pty slave. Although potentially
      exploitable by a malicious program running a setuid program on
      a pty slave, it's unknown if this exploit currently exists.
      
      Limit to signals actually used.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Howard Chu <hyc@symas.com>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      09179f19
    • Matthew Wilcox's avatar
      axonram: Fix bug in direct_access · 3e8f5879
      Matthew Wilcox authored
      commit 91117a20 upstream.
      
      The 'pfn' returned by axonram was completely bogus, and has been since
      2008.
      Signed-off-by: default avatarMatthew Wilcox <matthew.r.wilcox@intel.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      3e8f5879
    • Jeff Moyer's avatar
      cfq-iosched: fix incorrect filing of rt async cfqq · cb5085fd
      Jeff Moyer authored
      commit c6ce1943 upstream.
      
      Hi,
      
      If you can manage to submit an async write as the first async I/O from
      the context of a process with realtime scheduling priority, then a
      cfq_queue is allocated, but filed into the wrong async_cfqq bucket.  It
      ends up in the best effort array, but actually has realtime I/O
      scheduling priority set in cfqq->ioprio.
      
      The reason is that cfq_get_queue assumes the default scheduling class and
      priority when there is no information present (i.e. when the async cfqq
      is created):
      
      static struct cfq_queue *
      cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
      	      struct bio *bio, gfp_t gfp_mask)
      {
      	const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
      	const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
      
      cic->ioprio starts out as 0, which is "invalid".  So, class of 0
      (IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so:
      
      		async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
      
      static struct cfq_queue **
      cfq_async_queue_prio(struct cfq_data *cfqd, int ioprio_class, int ioprio)
      {
              switch (ioprio_class) {
              case IOPRIO_CLASS_RT:
                      return &cfqd->async_cfqq[0][ioprio];
              case IOPRIO_CLASS_NONE:
                      ioprio = IOPRIO_NORM;
                      /* fall through */
              case IOPRIO_CLASS_BE:
                      return &cfqd->async_cfqq[1][ioprio];
              case IOPRIO_CLASS_IDLE:
                      return &cfqd->async_idle_cfqq;
              default:
                      BUG();
              }
      }
      
      Here, instead of returning a class mapped from the process' scheduling
      priority, we get back the bucket associated with IOPRIO_CLASS_BE.
      
      Now, there is no queue allocated there yet, so we create it:
      
      		cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask);
      
      That function ends up doing this:
      
      			cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync);
      			cfq_init_prio_data(cfqq, cic);
      
      cfq_init_cfqq marks the priority as having changed.  Then, cfq_init_prio
      data does this:
      
      	ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
      	switch (ioprio_class) {
      	default:
      		printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
      	case IOPRIO_CLASS_NONE:
      		/*
      		 * no prio set, inherit CPU scheduling settings
      		 */
      		cfqq->ioprio = task_nice_ioprio(tsk);
      		cfqq->ioprio_class = task_nice_ioclass(tsk);
      		break;
      
      So we basically have two code paths that treat IOPRIO_CLASS_NONE
      differently, which results in an RT async cfqq filed into a best effort
      bucket.
      
      Attached is a patch which fixes the problem.  I'm not sure how to make
      it cleaner.  Suggestions would be welcome.
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Tested-by: default avatarHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      cb5085fd
    • Konstantin Khlebnikov's avatar
      cfq-iosched: handle failure of cfq group allocation · c7d68c69
      Konstantin Khlebnikov authored
      commit 69abaffe upstream.
      
      Cfq_lookup_create_cfqg() allocates struct blkcg_gq using GFP_ATOMIC.
      In cfq_find_alloc_queue() possible allocation failure is not handled.
      As a result kernel oopses on NULL pointer dereference when
      cfq_link_cfqq_cfqg() calls cfqg_get() for NULL pointer.
      
      Bug was introduced in v3.5 in commit cd1604fa ("blkcg: factor
      out blkio_group creation"). Prior to that commit cfq group lookup
      had returned pointer to root group as fallback.
      
      This patch handles this error using existing fallback oom_cfqq.
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Fixes: cd1604fa ("blkcg: factor out blkio_group creation")
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      c7d68c69
    • Nicholas Bellinger's avatar
      iscsi-target: Drop problematic active_ts_list usage · a291f65d
      Nicholas Bellinger authored
      commit 3fd7b60f upstream.
      
      This patch drops legacy active_ts_list usage within iscsi_target_tq.c
      code.  It was originally used to track the active thread sets during
      iscsi-target shutdown, and is no longer used by modern upstream code.
      
      Two people have reported list corruption using traditional iscsi-target
      and iser-target with the following backtrace, that appears to be related
      to iscsi_thread_set->ts_list being used across both active_ts_list and
      inactive_ts_list.
      
      [   60.782534] ------------[ cut here ]------------
      [   60.782543] WARNING: CPU: 0 PID: 9430 at lib/list_debug.c:53 __list_del_entry+0x63/0xd0()
      [   60.782545] list_del corruption, ffff88045b00d180->next is LIST_POISON1 (dead000000100100)
      [   60.782546] Modules linked in: ib_srpt tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc scsi_tgt ib_isert rdma_cm iw_cm ib_addr iscsi_target_mod target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en mlx4_ib ib_sa ib_mad ib_core mlx4_core dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support microcode serio_raw pcspkr sb_edac edac_core sg i2c_i801 lpc_ich mfd_core mtip32xx igb i2c_algo_bit i2c_core ptp pps_core ioatdma dca wmi ext3(F) jbd(F) mbcache(F) sd_mod(F) crc_t10dif(F) crct10dif_common(F) ahci(F) libahci(F) isci(F) libsas(F) scsi_transport_sas(F) [last unloaded: speedstep_lib]
      [   60.782597] CPU: 0 PID: 9430 Comm: iscsi_ttx Tainted: GF 3.12.19+ #2
      [   60.782598] Hardware name: Supermicro X9DRX+-F/X9DRX+-F, BIOS 3.00 07/09/2013
      [   60.782599]  0000000000000035 ffff88044de31d08 ffffffff81553ae7 0000000000000035
      [   60.782602]  ffff88044de31d58 ffff88044de31d48 ffffffff8104d1cc 0000000000000002
      [   60.782605]  ffff88045b00d180 ffff88045b00d0c0 ffff88045b00d0c0 ffff88044de31e58
      [   60.782607] Call Trace:
      [   60.782611]  [<ffffffff81553ae7>] dump_stack+0x49/0x62
      [   60.782615]  [<ffffffff8104d1cc>] warn_slowpath_common+0x8c/0xc0
      [   60.782618]  [<ffffffff8104d2b6>] warn_slowpath_fmt+0x46/0x50
      [   60.782620]  [<ffffffff81280933>] __list_del_entry+0x63/0xd0
      [   60.782622]  [<ffffffff812809b1>] list_del+0x11/0x40
      [   60.782630]  [<ffffffffa06e7cf9>] iscsi_del_ts_from_active_list+0x29/0x50 [iscsi_target_mod]
      [   60.782635]  [<ffffffffa06e87b1>] iscsi_tx_thread_pre_handler+0xa1/0x180 [iscsi_target_mod]
      [   60.782642]  [<ffffffffa06fb9ae>] iscsi_target_tx_thread+0x4e/0x220 [iscsi_target_mod]
      [   60.782647]  [<ffffffffa06fb960>] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod]
      [   60.782652]  [<ffffffffa06fb960>] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod]
      [   60.782655]  [<ffffffff8106f99e>] kthread+0xce/0xe0
      [   60.782657]  [<ffffffff8106f8d0>] ? kthread_freezable_should_stop+0x70/0x70
      [   60.782660]  [<ffffffff8156026c>] ret_from_fork+0x7c/0xb0
      [   60.782662]  [<ffffffff8106f8d0>] ? kthread_freezable_should_stop+0x70/0x70
      [   60.782663] ---[ end trace 9662f4a661d33965 ]---
      
      Since this code is no longer used, go ahead and drop the problematic usage
      all-together.
      Reported-by: default avatarGavin Guo <gavin.guo@canonical.com>
      Reported-by: default avatarMoussa Ba <moussaba@micron.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a291f65d
    • Trond Myklebust's avatar
      NFSv4.1: Fix a kfree() of uninitialised pointers in decode_cb_sequence_args · 7ccb9a76
      Trond Myklebust authored
      commit d8ba1f97 upstream.
      
      If the call to decode_rc_list() fails due to a memory allocation error,
      then we need to truncate the array size to ensure that we only call
      kfree() on those pointer that were allocated.
      Reported-by: default avatarDavid Ramos <daramos@stanford.edu>
      Fixes: 4aece6a1 ("nfs41: cb_sequence xdr implementation")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      7ccb9a76
    • honclo's avatar
      Added Little Endian support to vtpm module · bcb8bcd1
      honclo authored
      commit eb71f8a5 upstream.
      
      The tpm_ibmvtpm module is affected by an unaligned access problem.
      ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
      enabled in Power partition, which supports both little endian and
      big endian modes.
      
      We added little endian support to fix this problem:
      1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
      2) added be16_to_cpu and be32_to_cpu calls to make sure data received
         is in LE format on a LE OS.
      Signed-off-by: default avatarHon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com>
      Signed-off-by: default avatarJoy Latten <jmlatten@linux.vnet.ibm.com>
      [phuewe: manually applied the patch :( ]
      Reviewed-by: default avatarAshley Lai <ashley@ahsleylai.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      bcb8bcd1
    • Christophe Ricard's avatar
      tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send · 575bc4a1
      Christophe Ricard authored
      commit 1ba3b0b6 upstream.
      
      When sending data in tpm_stm_i2c_send, each loop iteration send buf.
      Send buf + i instead as the goal of this for loop is to send a number
      of byte from buf that fit in burstcnt. Once those byte are sent, we are
      supposed to send the next ones.
      
      The driver was working because the burstcount value returns always the maximum size for a TPM
      command or response. (0x800 for a command and 0x400 for a response).
      Reviewed-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      575bc4a1
    • Hon Ching (Vicky) Lo's avatar
      tpm: Fix NULL return in tpm_ibmvtpm_get_desired_dma · 3d968940
      Hon Ching (Vicky) Lo authored
      commit 84eb186b upstream.
      
      There was an oops in tpm_ibmvtpm_get_desired_dma, which caused
      kernel panic during boot when vTPM is enabled in Power partition
      configured in AMS mode.
      
      vio_bus_probe calls vio_cmo_bus_probe which calls
      tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation.
      The problem is, vio_cmo_bus_probe is called before calling probe, which
      for vtpm is tpm_ibmvtpm_probe and it's this function that initializes
      and sets up vtpm's CRQ and gets required data values.  Therefore,
      since this has not yet been done, NULL is returned in attempt to get
      the size for DMA allocation.
      
      We added a NULL check.  In addition, a default buffer size will
      be set when NULL is returned.
      Signed-off-by: default avatarHon Ching (Vicky) Lo <honclo@linux.vnet.ibm.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      3d968940
    • David Howells's avatar
      TPM: Add new TPMs to the tail of the list to prevent inadvertent change of dev · b896ee97
      David Howells authored
      commit 398a1e71 upstream.
      
      Add newly registered TPMs to the tail of the list, not the beginning, so that
      things that are specifying TPM_ANY_NUM don't find that the device they're
      using has inadvertently changed.  Adding a second device would break IMA, for
      instance.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b896ee97
    • Scot Doyle's avatar
      tpm_tis: verify interrupt during init · 8b931191
      Scot Doyle authored
      commit 448e9c55 upstream.
      
      Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
      not send IRQs while also having an ACPI TPM entry indicating that they
      will be sent. These machines freeze on resume while the tpm_tis module
      waits for an IRQ, eventually timing out.
      
      When in interrupt mode, the tpm_tis module should receive an IRQ during
      module init. Fall back to polling mode if none is received when expected.
      Signed-off-by: default avatarScot Doyle <lkml14@scotdoyle.com>
      Tested-by: default avatarMichael Mullin <masmullin@gmail.com>
      Reviewed-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      [phuewe: minor checkpatch fixed]
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8b931191
    • Robert Nelson's avatar
      ARM: dts: am335x-bone*: usb0 is hardwired for peripheral · f202b811
      Robert Nelson authored
      commit 67fd14b3 upstream.
      
      Fixes: http://bugs.elinux.org/issues/127
      
      the bb.org community was seeing random reboots before this change.
      Signed-off-by: default avatarRobert Nelson <robertcnelson@gmail.com>
      Reviewed-by: default avatarFelipe Balbi <balbi@ti.com>
      Acked-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f202b811
    • Lokesh Vutla's avatar
      ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 · bb401d9b
      Lokesh Vutla authored
      commit 1c7e36bf upstream.
      
      With commit '7dedd346: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset()
      with DEBUG_LL' we moved from parsing cmdline to identify uart used
      for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
      
      On DRA7 UART3 hwmod doesn't have this flag enabled, and atleast on
      BeagleBoard-X15, where we use UART3 for console, boot fails with
      DEBUG_LL enabled. Enable DEBUG_OMAP4UART3_FLAGS for UART3 hwmod.
      
      For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig.
      
      Fixes: 90020c7b ("ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data")
      Reviewed-by: default avatarFelipe Balbi <balbi@ti.com>
      Acked-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      bb401d9b
    • Dmitry Eremin-Solenikov's avatar
      ARM: 8284/1: sa1100: clear RCSR_SMR on resume · 2b14545f
      Dmitry Eremin-Solenikov authored
      commit e461894d upstream.
      
      StrongARM core uses RCSR SMR bit to tell to bootloader that it was reset
      by entering the sleep mode. After we have resumed, there is little point
      in having that bit enabled. Moreover, if this bit is set before reboot,
      the bootloader can become confused. Thus clear the SMR bit on resume
      just before clearing the scratchpad (resume address) register.
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2b14545f
    • Vikram Mulukutla's avatar
      tracing: Fix unmapping loop in tracing_mark_write · d016c1bd
      Vikram Mulukutla authored
      commit 7215853e upstream.
      
      Commit 6edb2a8a introduced
      an array map_pages that contains the addresses returned by
      kmap_atomic. However, when unmapping those pages, map_pages[0]
      is unmapped before map_pages[1], breaking the nesting requirement
      as specified in the documentation for kmap_atomic/kunmap_atomic.
      
      This was caught by the highmem debug code present in kunmap_atomic.
      Fix the loop to do the unmapping properly.
      
      Link: http://lkml.kernel.org/r/1418871056-6614-1-git-send-email-markivx@codeaurora.orgReviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Reported-by: default avatarLime Yang <limey@codeaurora.org>
      Signed-off-by: default avatarVikram Mulukutla <markivx@codeaurora.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d016c1bd
    • Naoya Horiguchi's avatar
      mm/hugetlb: pmd_huge() returns true for non-present hugepage · 28d38853
      Naoya Horiguchi authored
      commit cbef8478 upstream.
      
      Migrating hugepages and hwpoisoned hugepages are considered as non-present
      hugepages, and they are referenced via migration entries and hwpoison
      entries in their page table slots.
      
      This behavior causes race condition because pmd_huge() doesn't tell
      non-huge pages from migrating/hwpoisoned hugepages.  follow_page_mask() is
      one example where the kernel would call follow_page_pte() for such
      hugepage while this function is supposed to handle only normal pages.
      
      To avoid this, this patch makes pmd_huge() return true when pmd_none() is
      true *and* pmd_present() is false.  We don't have to worry about mixing up
      non-present pmd entry with normal pmd (pointing to leaf level pte entry)
      because pmd_present() is true in normal pmd.
      
      The same race condition could happen in (x86-specific) gup_pmd_range(),
      where this patch simply adds pmd_present() check instead of pmd_huge().
      This is because gup_pmd_range() is fast path.  If we have non-present
      hugepage in this function, we will go into gup_huge_pmd(), then return 0
      at flag mask check, and finally fall back to the slow path.
      
      Fixes: 290408d4 ("hugetlb: hugepage migration core")
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Luiz Capitulino <lcapitulino@redhat.com>
      Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Steve Capper <steve.capper@linaro.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 avatarJiri Slaby <jslaby@suse.cz>
      28d38853
    • James Hogan's avatar
      MIPS: KVM: Deliver guest interrupts after local_irq_disable() · 2301499b
      James Hogan authored
      commit 044f0f03 upstream.
      
      When about to run the guest, deliver guest interrupts after disabling
      host interrupts. This should prevent an hrtimer interrupt from being
      handled after delivering guest interrupts, and therefore not delivering
      the guest timer interrupt until after the next guest exit.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: kvm@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: Sanjay Lal <sanjayl@kymasys.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2301499b
    • Jeff Layton's avatar
      nfs: don't call blocking operations while !TASK_RUNNING · 2f81b70c
      Jeff Layton authored
      commit 6ffa30d3 upstream.
      
      Bruce reported seeing this warning pop when mounting using v4.1:
      
           ------------[ cut here ]------------
           WARNING: CPU: 1 PID: 1121 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
          do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810ff58f>] prepare_to_wait+0x2f/0x90
          Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer ppdev joydev snd virtio_console virtio_balloon pcspkr serio_raw parport_pc parport pvpanic floppy soundcore i2c_piix4 virtio_blk virtio_net qxl drm_kms_helper ttm drm virtio_pci virtio_ring ata_generic virtio pata_acpi
          CPU: 1 PID: 1121 Comm: nfsv4.1-svc Not tainted 3.19.0-rc4+ #25
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014
           0000000000000000 000000004e5e3f73 ffff8800b998fb48 ffffffff8186ac78
           0000000000000000 ffff8800b998fba0 ffff8800b998fb88 ffffffff810ac9da
           ffff8800b998fb68 ffffffff81c923e7 00000000000004d9 0000000000000000
          Call Trace:
           [<ffffffff8186ac78>] dump_stack+0x4c/0x65
           [<ffffffff810ac9da>] warn_slowpath_common+0x8a/0xc0
           [<ffffffff810aca65>] warn_slowpath_fmt+0x55/0x70
           [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90
           [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90
           [<ffffffff810dd2ad>] __might_sleep+0xbd/0xd0
           [<ffffffff8124c973>] kmem_cache_alloc_trace+0x243/0x430
           [<ffffffff810d941e>] ? groups_alloc+0x3e/0x130
           [<ffffffff810d941e>] groups_alloc+0x3e/0x130
           [<ffffffffa0301b1e>] svcauth_unix_accept+0x16e/0x290 [sunrpc]
           [<ffffffffa0300571>] svc_authenticate+0xe1/0xf0 [sunrpc]
           [<ffffffffa02fc564>] svc_process_common+0x244/0x6a0 [sunrpc]
           [<ffffffffa02fd044>] bc_svc_process+0x1c4/0x260 [sunrpc]
           [<ffffffffa03d5478>] nfs41_callback_svc+0x128/0x1f0 [nfsv4]
           [<ffffffff810ff970>] ? wait_woken+0xc0/0xc0
           [<ffffffffa03d5350>] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
           [<ffffffff810d45bf>] kthread+0x11f/0x140
           [<ffffffff810ea815>] ? local_clock+0x15/0x30
           [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250
           [<ffffffff81874bfc>] ret_from_fork+0x7c/0xb0
           [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250
          ---[ end trace 675220a11e30f4f2 ]---
      
      nfs41_callback_svc does most of its work while in TASK_INTERRUPTIBLE,
      which is just wrong. Fix that by finishing the wait immediately if we've
      found that the list has something on it.
      
      Also, we don't expect this kthread to accept signals, so we should be
      using a TASK_UNINTERRUPTIBLE sleep instead. That however, opens us up
      hung task warnings from the watchdog, so have the schedule_timeout
      wake up every 60s if there's no callback activity.
      Reported-by: default avatar"J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2f81b70c
    • Jisheng Zhang's avatar
      mmc: sdhci-pxav3: fix setting of pdata->clk_delay_cycles · 04333c0b
      Jisheng Zhang authored
      commit 14460dba upstream.
      
      Current code checks "clk_delay_cycles > 0" to know whether the optional
      "mrvl,clk_delay_cycles" is set or not. But of_property_read_u32() doesn't
      touch clk_delay_cycles if the property is not set. And type of
      clk_delay_cycles is u32, so we may always set pdata->clk_delay_cycles as a
      random value.
      
      This patch fix this problem by check the return value of of_property_read_u32()
      to know whether the optional clk-delay-cycles is set or not.
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      04333c0b
    • Sumit.Saxena@avagotech.com's avatar
      megaraid_sas: disable interrupt_mask before enabling hardware interrupts · 5e1b3dc7
      Sumit.Saxena@avagotech.com authored
      commit c2ced171 upstream.
      
      Update driver "mask_interrupts" before enable/disable hardware interrupt
      in order to avoid missing interrupts because of "mask_interrupts" still
      set to 1 and hardware interrupts are enabled.
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@avagotech.com>
      Signed-off-by: default avatarChaitra Basappa <chaitra.basappa@avagotech.com>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      5e1b3dc7
    • Krzysztof Kozlowski's avatar
      power: bq24190: Fix ignored supplicants · 20f1c878
      Krzysztof Kozlowski authored
      commit 478913fd upstream.
      
      The driver mismatched 'num_supplicants' with 'num_supplies' of
      power_supply structure.
      
      It provided list of supplicants (power_supply.supplied_to) but did
      not set the number of supplicants. Instead it set the num_supplies which
      is used when iterating over number of supplies (power_supply.supplied_from).
      
      As a result the list of supplicants was ignored by core because its size
      was 0.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      20f1c878