1. 01 Mar, 2015 40 commits
    • 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
    • Krzysztof Kozlowski's avatar
      power_supply: 88pm860x: Fix leaked power supply on probe fail · af3de02e
      Krzysztof Kozlowski authored
      commit 24727b45 upstream.
      
      Driver forgot to unregister power supply if request_threaded_irq()
      failed in probe(). In such case the memory associated with power supply
      leaked.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: a830d28b ("power_supply: Enable battery-charger for 88pm860x")
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      af3de02e
    • Adrian Knoth's avatar
      ALSA: hdspm - Constrain periods to 2 on older cards · a80c9329
      Adrian Knoth authored
      commit f0153c3d upstream.
      
      RME RayDAT and AIO use a fixed buffer size of 16384 samples. With period
      sizes of 32-4096, this translates to 4-512 periods.
      
      The older RME cards have a variable buffer size but require exactly two
      periods.
      
      This patch enforces nperiods=2 on those cards.
      Signed-off-by: default avatarAdrian Knoth <adi@drcomp.erfurt.thur.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a80c9329
    • Dan Carpenter's avatar
      ALSA: off by one bug in snd_riptide_joystick_probe() · 60a50539
      Dan Carpenter authored
      commit e4940626 upstream.
      
      The problem here is that we check:
      
      	if (dev >= SNDRV_CARDS)
      
      Then we increment "dev".
      
             if (!joystick_port[dev++])
      
      Then we use it as an offset into a array with SNDRV_CARDS elements.
      
      	if (!request_region(joystick_port[dev], 8, "Riptide gameport")) {
      
      This has 3 effects:
      1) If you use the module option to specify the joystick port then it has
         to be shifted one space over.
      2) The wrong error message will be printed on failure if you have over
         32 cards.
      3) Static checkers will correctly complain that are off by one.
      
      Fixes: db1005ec ('ALSA: riptide - Fix joystick resource handling')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      60a50539
    • Malcolm Priestley's avatar
      lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb · 63935f3d
      Malcolm Priestley authored
      commit 15e1ce33 upstream.
      
      A quirk of some older firmwares that report endpoint pipe type as PIPE_BULK
      but the endpoint otheriwse functions as interrupt.
      
      Check if usb_endpoint_type is USB_ENDPOINT_XFER_BULK and set as usb_rcvbulkpipe.
      Signed-off-by: default avatarMalcolm Priestley <tvboxspy@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      63935f3d
    • Ross Lagerwall's avatar
      xen/manage: Fix USB interaction issues when resuming · 9e012b00
      Ross Lagerwall authored
      commit 72978b2f upstream.
      
      Commit 61a734d3 ("xen/manage: Always freeze/thaw processes when
      suspend/resuming") ensured that userspace processes were always frozen
      before suspending to reduce interaction issues when resuming devices.
      However, freeze_processes() does not freeze kernel threads.  Freeze
      kernel threads as well to prevent deadlocks with the khubd thread when
      resuming devices.
      
      This is what native suspend and resume does.
      
      Example deadlock:
      [ 7279.648010]  [<ffffffff81446bde>] ? xen_poll_irq_timeout+0x3e/0x50
      [ 7279.648010]  [<ffffffff81448d60>] xen_poll_irq+0x10/0x20
      [ 7279.648010]  [<ffffffff81011723>] xen_lock_spinning+0xb3/0x120
      [ 7279.648010]  [<ffffffff810115d1>] __raw_callee_save_xen_lock_spinning+0x11/0x20
      [ 7279.648010]  [<ffffffff815620b6>] ? usb_control_msg+0xe6/0x120
      [ 7279.648010]  [<ffffffff81747e50>] ? _raw_spin_lock_irq+0x50/0x60
      [ 7279.648010]  [<ffffffff8174522c>] wait_for_completion+0xac/0x160
      [ 7279.648010]  [<ffffffff8109c520>] ? try_to_wake_up+0x2c0/0x2c0
      [ 7279.648010]  [<ffffffff814b60f2>] dpm_wait+0x32/0x40
      [ 7279.648010]  [<ffffffff814b6eb0>] device_resume+0x90/0x210
      [ 7279.648010]  [<ffffffff814b7d71>] dpm_resume+0x121/0x250
      [ 7279.648010]  [<ffffffff8144c570>] ? xenbus_dev_request_and_reply+0xc0/0xc0
      [ 7279.648010]  [<ffffffff814b80d5>] dpm_resume_end+0x15/0x30
      [ 7279.648010]  [<ffffffff81449fba>] do_suspend+0x10a/0x200
      [ 7279.648010]  [<ffffffff8144a2f0>] ? xen_pre_suspend+0x20/0x20
      [ 7279.648010]  [<ffffffff8144a1d0>] shutdown_handler+0x120/0x150
      [ 7279.648010]  [<ffffffff8144c60f>] xenwatch_thread+0x9f/0x160
      [ 7279.648010]  [<ffffffff810ac510>] ? finish_wait+0x80/0x80
      [ 7279.648010]  [<ffffffff8108d189>] kthread+0xc9/0xe0
      [ 7279.648010]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
      [ 7279.648010]  [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0
      [ 7279.648010]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
      
      [ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds.
      [ 7441.219457]       Tainted: G            X 3.13.11-ckt12.kz #1
      [ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 7441.225827] khubd           D ffff88003f433440     0    89      2 0x00000000
      [ 7441.229258]  ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440
      [ 7441.232959]  ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000
      [ 7441.236658]  0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e
      [ 7441.240415] Call Trace:
      [ 7441.241614]  [<ffffffff817442f9>] schedule+0x29/0x70
      [ 7441.243930]  [<ffffffff81743406>] schedule_timeout+0x166/0x2c0
      [ 7441.246681]  [<ffffffff81075b80>] ? call_timer_fn+0x110/0x110
      [ 7441.249339]  [<ffffffff8174357e>] schedule_timeout_uninterruptible+0x1e/0x20
      [ 7441.252644]  [<ffffffff81077710>] msleep+0x20/0x30
      [ 7441.254812]  [<ffffffff81555f00>] hub_port_reset+0xf0/0x580
      [ 7441.257400]  [<ffffffff81558465>] hub_port_init+0x75/0xb40
      [ 7441.259981]  [<ffffffff814bb3c9>] ? update_autosuspend+0x39/0x60
      [ 7441.262817]  [<ffffffff814bb4f0>] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
      [ 7441.266212]  [<ffffffff8155a64a>] hub_thread+0x71a/0x1750
      [ 7441.268728]  [<ffffffff810ac510>] ? finish_wait+0x80/0x80
      [ 7441.271272]  [<ffffffff81559f30>] ? usb_port_resume+0x670/0x670
      [ 7441.274067]  [<ffffffff8108d189>] kthread+0xc9/0xe0
      [ 7441.276305]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
      [ 7441.279131]  [<ffffffff8175087c>] ret_from_fork+0x7c/0xb0
      [ 7441.281659]  [<ffffffff8108d0c0>] ? flush_kthread_worker+0x80/0x80
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9e012b00
    • Arnd Bergmann's avatar
      cpufreq: s3c: remove incorrect __init annotations · 206b039c
      Arnd Bergmann authored
      commit 61882b63 upstream.
      
      The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register
      are marked init but are called from a context that might be run after
      the __init sections are discarded, as the compiler points out:
      
      WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init()
      WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register()
      
      This removes the __init markings.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      206b039c
    • Mikulas Patocka's avatar
      cpufreq: speedstep-smi: enable interrupts when waiting · 442a1765
      Mikulas Patocka authored
      commit d4d4eda2 upstream.
      
      On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
      speedstep-smi driver sometimes loads and sometimes doesn't load with
      "change to state X failed" message.
      
      The hardware sometimes refuses to change frequency and in this case, we
      need to retry later. I found out that we need to enable interrupts while
      waiting. When we enable interrupts, the hardware blockage that prevents
      frequency transition resolves and the transition is possible. With
      disabled interrupts, the blockage doesn't resolve (no matter how long do
      we wait). The exact reasons for this hardware behavior are unknown.
      
      This patch enables interrupts in the function speedstep_set_state that can
      be called with disabled interrupts. However, this function is called with
      disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
      any problem.
      
      Signed-off-by: Mikulas Patocka <mpatocka@redhat.com
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      442a1765
    • Michel Dänzer's avatar
      PCI: Fix infinite loop with ROM image of size 0 · bd4b3c10
      Michel Dänzer authored
      commit 16b036af upstream.
      
      If the image size would ever read as 0, pci_get_rom_size() could keep
      processing the same image over and over again.  Exit the loop if we ever
      read a length of zero.
      
      This fixes a soft lockup on boot when the radeon driver calls
      pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.
      
      [bhelgaas: changelog, reference]
      Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973Reported-by: default avatarFederico <federicotg@gmail.com>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      bd4b3c10
    • Ricardo Ribalda Delgado's avatar
      PCI: Generate uppercase hex for modalias var in uevent · 109102cb
      Ricardo Ribalda Delgado authored
      commit 145b3fe5 upstream.
      
      Some implementations of modprobe fail to load the driver for a PCI device
      automatically because the "interface" part of the modalias from the kernel
      is lowercase, and the modalias from file2alias is uppercase.
      
      The "interface" is the low-order byte of the Class Code, defined in PCI
      r3.0, Appendix D.  Most interface types defined in the spec do not use
      alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
      20h, etc. are unaffected.
      
      Print the "interface" byte of the Class Code in uppercase hex, as we
      already do for the Vendor ID, Device ID, Class, etc.
      
      Commit 89ec3dcf ("PCI: Generate uppercase hex for modalias interface
      class") fixed only half of the problem.  Some udev implementations rely on
      the uevent file and not the modalias file.
      
      Fixes: d1ded203 ("PCI: add MODALIAS to hotplug event for pci devices")
      Fixes: 89ec3dcf ("PCI: Generate uppercase hex for modalias interface class")
      Signed-off-by: default avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      109102cb
    • Seth Forshee's avatar
      HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events · 86705a9b
      Seth Forshee authored
      commit 6d00f37e upstream.
      
      d1c7e29e (HID: i2c-hid: prevent buffer overflow in early IRQ)
      changed hid_get_input() to read ihid->bufsize bytes, which can be
      more than wMaxInputLength. This is the case with the Dell XPS 13
      9343, and it is causing events to be missed. In some cases the
      missed events are releases, which can cause the cursor to jump or
      freeze, among other problems. Limit the number of bytes read to
      min(wMaxInputLength, ihid->bufsize) to prevent such problems.
      
      Fixes: d1c7e29e "HID: i2c-hid: prevent buffer overflow in early IRQ"
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      86705a9b
    • Luciano Coelho's avatar
      iwlwifi: mvm: always use mac color zero · a113cc3f
      Luciano Coelho authored
      commit 5523d11c upstream.
      
      We don't really need to use different mac colors when adding mac
      contexts, because they're not used anywhere.  In fact, the firmware
      doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401
      when we reach that.
      
      Remove the color increment to use always zero and avoid reaching 255.
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a113cc3f
    • Eyal Shapira's avatar
      iwlwifi: mvm: validate tid and sta_id in ba_notif · 9bb35f06
      Eyal Shapira authored
      commit 2cee4762 upstream.
      
      These are coming from the FW and are used to access arrays.
      Bad values can cause an out of bounds access so discard
      such ba_notifs and warn.
      Signed-off-by: default avatarEyal Shapira <eyalx.shapira@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9bb35f06
    • Emmanuel Grumbach's avatar
      iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN · ecbc35f5
      Emmanuel Grumbach authored
      commit cd8f4384 upstream.
      
      The base address of the scheduler in the device's memory
      (SRAM) comes from two different sources. The periphery
      register and the alive notification from the firmware.
      We have a check in iwl_pcie_tx_start that ensures that
      they are the same.
      When we resume from WoWLAN, the firmware may have crashed
      for whatever reason. In that case, the whole device may be
      reset which means that the periphery register will hold a
      meaningless value. When we come to compare
      trans_pcie->scd_base_addr (which really holds the value we
      had when we loaded the WoWLAN firmware upon suspend) and
      the current value of the register, we don't see a match
      unsurprisingly.
      Trick the check to avoid a loud yet harmless WARN.
      Note that when the WoWLAN has crashed, we will see that
      in iwl_trans_pcie_d3_resume which will let the op_mode
      know. Once the op_mode is informed that the WowLAN firmware
      has crashed, it can't do much besides resetting the whole
      device.
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ecbc35f5
    • Jan Kara's avatar
      fsnotify: fix handling of renames in audit · 30858d77
      Jan Kara authored
      commit 6ee8e25f upstream.
      
      Commit e9fd702a ("audit: convert audit watches to use fsnotify
      instead of inotify") broke handling of renames in audit.  Audit code
      wants to update inode number of an inode corresponding to watched name
      in a directory.  When something gets renamed into a directory to a
      watched name, inotify previously passed moved inode to audit code
      however new fsnotify code passes directory inode where the change
      happened.  That confuses audit and it starts watching parent directory
      instead of a file in a directory.
      
      This can be observed for example by doing:
      
        cd /tmp
        touch foo bar
        auditctl -w /tmp/foo
        touch foo
        mv bar foo
        touch foo
      
      In audit log we see events like:
      
        type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 op="updated rules" path="/tmp/foo" key=(null) list=4 res=1
        ...
        type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
        type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
        type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
        ...
      
      and that's it - we see event for the first touch after creating the
      audit rule, we see events for rename but we don't see any event for the
      last touch.  However we start seeing events for unrelated stuff
      happening in /tmp.
      
      Fix the problem by passing moved inode as data in the FS_MOVED_FROM and
      FS_MOVED_TO events instead of the directory where the change happens.
      This doesn't introduce any new problems because noone besides
      audit_watch.c cares about the passed value:
      
        fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events.
        fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all.
        fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH.
        kernel/audit_tree.c doesn't care about passed 'data' at all.
        kernel/audit_watch.c expects moved inode as 'data'.
      
      Fixes: e9fd702a ("audit: convert audit watches to use fsnotify instead of inotify")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Eric Paris <eparis@redhat.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 avatarJiri Slaby <jslaby@suse.cz>
      30858d77
    • Dave Chinner's avatar
      xfs: set superblock buffer type correctly · 33699d35
      Dave Chinner authored
      commit 3443a3bc upstream.
      
      When the superblock is modified in a transaction, the commonly
      modified fields are not actually copied to the superblock buffer to
      avoid the buffer lock becoming a serialisation point. However, there
      are some other operations that modify the superblock fields within
      the transaction that don't directly log to the superblock but rely
      on the changes to be applied during the transaction commit (to
      minimise the buffer lock hold time).
      
      When we do this, we fail to mark the buffer log item as being a
      superblock buffer and that can lead to the buffer not being marked
      with the corect type in the log and hence causing recovery issues.
      Fix it by setting the type correctly, similar to xfs_mod_sb()...
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      33699d35
    • Dave Chinner's avatar
      xfs: inode unlink does not set AGI buffer type · 7baee9ce
      Dave Chinner authored
      commit f19b872b upstream.
      
      This leads to log recovery throwing errors like:
      
      XFS (md0): Mounting V5 Filesystem
      XFS (md0): Starting recovery (logdev: internal)
      XFS (md0): Unknown buffer type 0!
      XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
      ffff8800ffc53800: 58 41 47 49 .....
      
      Which is the AGI buffer magic number.
      
      Ensure that we set the type appropriately in both unlink list
      addition and removal.
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      7baee9ce