1. 19 Oct, 2015 40 commits
    • Koji Matsuoka's avatar
      spi: sh-msiof: Fix FIFO size to 64 word from 256 word · a2273b6e
      Koji Matsuoka authored
      commit fe78d0b7 upstream.
      
      The upper limit of Tx/Rx FIFO size is 64 word by the
      specification of H/W. This patch corrects to 64 word from 256 word.
      Signed-off-by: default avatarKoji Matsuoka <koji.matsuoka.xm@renesas.com>
      Signed-off-by: default avatarYoshihiro Kaneko <ykaneko0929@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a2273b6e
    • Bart Van Assche's avatar
      IB/srp: Stop the scsi_eh_<n> and scsi_tmf_<n> threads if login fails · 68209189
      Bart Van Assche authored
      commit bc44bd1d upstream.
      
      scsi_host_alloc() not only allocates memory for a SCSI host but also
      creates the scsi_eh_<n> kernel thread and the scsi_tmf_<n> workqueue.
      Stop these threads if login fails by calling scsi_host_put().
      Reported-by: default avatarKonstantin Krotov <kkv@clodo.ru>
      Fixes: fb49c8bb ("Remove an extraneous scsi_host_put() from an error path")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      68209189
    • Bart Van Assche's avatar
      IB/srp: Handle partial connection success correctly · 0f3ea1a9
      Bart Van Assche authored
      commit c257ea6f upstream.
      
      Avoid that the following kernel warning is reported if the SRP
      target system accepts fewer channels per connection than what
      was requested by the initiator system:
      
      WARNING: at drivers/infiniband/ulp/srp/ib_srp.c:617 srp_destroy_qp+0xb1/0x120 [ib_srp]()
      Call Trace:
      [<ffffffff8105d67f>] warn_slowpath_common+0x7f/0xc0
      [<ffffffff8105d6da>] warn_slowpath_null+0x1a/0x20
      [<ffffffffa05419e1>] srp_destroy_qp+0xb1/0x120 [ib_srp]
      [<ffffffffa05445fb>] srp_create_ch_ib+0x19b/0x420 [ib_srp]
      [<ffffffffa0545257>] srp_create_target+0x7d7/0xa94 [ib_srp]
      [<ffffffff8138dac0>] dev_attr_store+0x20/0x30
      [<ffffffff812079ef>] sysfs_write_file+0xef/0x170
      [<ffffffff81191fc4>] vfs_write+0xb4/0x130
      [<ffffffff8119276f>] sys_write+0x5f/0xa0
      [<ffffffff815a0a59>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0f3ea1a9
    • David Dueck's avatar
      pinctrl: at91: fix null pointer dereference · 3742c891
      David Dueck authored
      commit 1ab36387 upstream.
      
      Not all gpio banks are necessarily enabled, in the current code this can
      lead to null pointer dereferences.
      
      [   51.130000] Unable to handle kernel NULL pointer dereference at virtual address 00000058
      [   51.130000] pgd = dee04000
      [   51.130000] [00000058] *pgd=3f66d831, *pte=00000000, *ppte=00000000
      [   51.140000] Internal error: Oops: 17 [#1] ARM
      [   51.140000] Modules linked in:
      [   51.140000] CPU: 0 PID: 1664 Comm: cat Not tainted 4.1.1+ #6
      [   51.140000] Hardware name: Atmel SAMA5
      [   51.140000] task: df6dd880 ti: dec60000 task.ti: dec60000
      [   51.140000] PC is at at91_pinconf_get+0xb4/0x200
      [   51.140000] LR is at at91_pinconf_get+0xb4/0x200
      [   51.140000] pc : [<c01e71a0>]    lr : [<c01e71a0>]    psr: 600f0013
      sp : dec61e48  ip : 600f0013  fp : df522538
      [   51.140000] r10: df52250c  r9 : 00000058  r8 : 00000068
      [   51.140000] r7 : 00000000  r6 : df53c910  r5 : 00000000  r4 : dec61e7c
      [   51.140000] r3 : 00000000  r2 : c06746d4  r1 : 00000000  r0 : 00000003
      [   51.140000] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [   51.140000] Control: 10c53c7d  Table: 3ee04059  DAC: 00000015
      [   51.140000] Process cat (pid: 1664, stack limit = 0xdec60208)
      [   51.140000] Stack: (0xdec61e48 to 0xdec62000)
      [   51.140000] 1e40:                   00000358 00000000 df522500 ded15f80 c05a9d08 ded15f80
      [   51.140000] 1e60: 0000048c 00000061 df522500 ded15f80 c05a9d08 c01e7304 ded15f80 00000000
      [   51.140000] 1e80: c01e6008 00000060 0000048c c01e6034 c01e5f6c ded15f80 dec61ec0 00000000
      [   51.140000] 1ea0: 00020000 ded6f280 dec61f80 00000001 00000001 c00ae0b8 b6e80000 ded15fb0
      [   51.140000] 1ec0: 00000000 00000000 df4bc974 00000055 00000800 ded6f280 b6e80000 ded6f280
      [   51.140000] 1ee0: ded6f280 00020000 b6e80000 00000000 00020000 c0090dec c0671e1c dec61fb0
      [   51.140000] 1f00: b6f8b510 00000001 00004201 c000924c 00000000 00000003 00000003 00000000
      [   51.140000] 1f20: df4bc940 00022000 00000022 c066e188 b6e7f000 c00836f4 000b6e7f ded6f280
      [   51.140000] 1f40: ded6f280 b6e80000 dec61f80 ded6f280 00020000 c0091508 00000000 00000003
      [   51.140000] 1f60: 00022000 00000000 00000000 ded6f280 ded6f280 00020000 b6e80000 c0091d9c
      [   51.140000] 1f80: 00000000 00000000 ffffffff 00020000 00020000 b6e80000 00000003 c000f124
      [   51.140000] 1fa0: dec60000 c000efa0 00020000 00020000 00000003 b6e80000 00020000 000271c4
      [   51.140000] 1fc0: 00020000 00020000 b6e80000 00000003 7fffe000 00000000 00000000 00020000
      [   51.140000] 1fe0: 00000000 bef50b64 00013835 b6f29c76 400f0030 00000003 00000000 00000000
      [   51.140000] [<c01e71a0>] (at91_pinconf_get) from [<c01e7304>] (at91_pinconf_dbg_show+0x18/0x2c0)
      [   51.140000] [<c01e7304>] (at91_pinconf_dbg_show) from [<c01e6034>] (pinconf_pins_show+0xc8/0xf8)
      [   51.140000] [<c01e6034>] (pinconf_pins_show) from [<c00ae0b8>] (seq_read+0x1a0/0x464)
      [   51.140000] [<c00ae0b8>] (seq_read) from [<c0090dec>] (__vfs_read+0x20/0xd0)
      [   51.140000] [<c0090dec>] (__vfs_read) from [<c0091508>] (vfs_read+0x7c/0x108)
      [   51.140000] [<c0091508>] (vfs_read) from [<c0091d9c>] (SyS_read+0x40/0x94)
      [   51.140000] [<c0091d9c>] (SyS_read) from [<c000efa0>] (ret_fast_syscall+0x0/0x3c)
      [   51.140000] Code: eb010ec2 e30a0d08 e34c005a eb0ae5a7 (e5993000)
      [   51.150000] ---[ end trace fb3c370da3ea4794 ]---
      
      Fixes: a0b957f3 ("pinctrl: at91: allow to have disabled gpio bank")
      Signed-off-by: default avatarDavid Dueck <davidcdueck@googlemail.com>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
      Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3742c891
    • Mike Marciniszyn's avatar
      IB/qib: Change lkey table allocation to support more MRs · 62c41ff6
      Mike Marciniszyn authored
      commit d6f1c17e upstream.
      
      The lkey table is allocated with with a get_user_pages() with an
      order based on a number of index bits from a module parameter.
      
      The underlying kernel code cannot allocate that many contiguous pages.
      
      There is no reason the underlying memory needs to be physically
      contiguous.
      
      This patch:
      - switches the allocation/deallocation to vmalloc/vfree
      - caps the number of bits to 23 to insure at least 1 generation bit
        o this matches the module parameter description
      Reviewed-by: default avatarVinit Agnihotri <vinit.abhay.agnihotri@intel.com>
      Signed-off-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      62c41ff6
    • Yao-Wen Mao's avatar
      ALSA: usb-audio: correct the value cache check. · 40884cf6
      Yao-Wen Mao authored
      commit 6aa6925c upstream.
      
      The check of cval->cached should be zero-based (including master channel).
      Signed-off-by: default avatarYao-Wen Mao <yaowen@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      40884cf6
    • David Jeffery's avatar
      xfs: return errors from partial I/O failures to files · f68c0f39
      David Jeffery authored
      commit c9eb256e upstream.
      
      There is an issue with xfs's error reporting in some cases of I/O partially
      failing and partially succeeding. Calls like fsync() can report success even
      though not all I/O was successful in partial-failure cases such as one disk of
      a RAID0 array being offline.
      
      The issue can occur when there are more than one bio per xfs_ioend struct.
      Each call to xfs_end_bio() for a bio completing will write a value to
      ioend->io_error.  If a successful bio completes after any failed bio, no
      error is reported do to it writing 0 over the error code set by any failed bio.
      The I/O error information is now lost and when the ioend is completed
      only success is reported back up the filesystem stack.
      
      xfs_end_bio() should only set ioend->io_error in the case of BIO_UPTODATE
      being clear.  ioend->io_error is initialized to 0 at allocation so only needs
      to be updated by a failed bio. Also check that ioend->io_error is 0 so that
      the first error reported will be the error code returned.
      Signed-off-by: default avatarDavid Jeffery <djeffery@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f68c0f39
    • Marek Szyprowski's avatar
      clk: s5pv210: add missing call to samsung_clk_of_add_provider() · 9a33faea
      Marek Szyprowski authored
      commit ba300115 upstream.
      
      Commit d5e136a2 ("clk: samsung: Register
      clk provider only after registering its all clocks", merged to v3.17-rc1)
      modified a way that driver registers registers to core framework. This
      change has not been applied to s5pv210 clocks driver, which has been
      merged in parallel to that commit. This patch adds a missing call to
      samsung_clk_of_add_provider(), so the driver is operational again.
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Acked-by: default avatarTomasz Figa <tomasz.figa@gmail.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9a33faea
    • Adam Lee's avatar
      mmc: sdhci-pci: set the clear transfer mode register quirk for O2Micro · 8e7c75fa
      Adam Lee authored
      commit 143b648d upstream.
      
      This patch fixes MMC not working issue on O2Micro/BayHub Host, which
      requires transfer mode register to be cleared when sending no DMA
      command.
      Signed-off-by: default avatarPeter Guo <peter.guo@bayhubtech.com>
      Signed-off-by: default avatarAdam Lee <adam.lee@canonical.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8e7c75fa
    • Ard Biesheuvel's avatar
      arm64: flush FP/SIMD state correctly after execve() · fadafd14
      Ard Biesheuvel authored
      commit 674c242c upstream.
      
      When a task calls execve(), its FP/SIMD state is flushed so that
      none of the original program state is observeable by the incoming
      program.
      
      However, since this flushing consists of setting the in-memory copy
      of the FP/SIMD state to all zeroes, the CPU field is set to CPU 0 as
      well, which indicates to the lazy FP/SIMD preserve/restore code that
      the FP/SIMD state does not need to be reread from memory if the task
      is scheduled again on CPU 0 without any other tasks having entered
      userland (or used the FP/SIMD in kernel mode) on the same CPU in the
      mean time. If this happens, the FP/SIMD state of the old program will
      still be present in the registers when the new program starts.
      
      So set the CPU field to the invalid value of NR_CPUS when performing
      the flush, by calling fpsimd_flush_task_state().
      Reported-by: default avatarChunyan Zhang <chunyan.zhang@spreadtrum.com>
      Reported-by: default avatarJanet Liu <janet.liu@spreadtrum.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      fadafd14
    • Grant Likely's avatar
      drivercore: Fix unregistration path of platform devices · a150cc58
      Grant Likely authored
      commit 7f5dcaf1 upstream.
      
      The unregister path of platform_device is broken. On registration, it
      will register all resources with either a parent already set, or
      type==IORESOURCE_{IO,MEM}. However, on unregister it will release
      everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
      are also cases where resources don't get registered in the first place,
      like with devices created by of_platform_populate()*.
      
      Fix the unregister path to be symmetrical with the register path by
      checking the parent pointer instead of the type field to decide which
      resources to unregister. This is safe because the upshot of the
      registration path algorithm is that registered resources have a parent
      pointer, and non-registered resources do not.
      
      * It can be argued that of_platform_populate() should be registering
        it's resources, and they argument has some merit. However, there are
        quite a few platforms that end up broken if we try to do that due to
        overlapping resources in the device tree. Until that is fixed, we need
        to solve the immediate problem.
      
      Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Tested-by: default avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Tested-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a150cc58
    • David Daney's avatar
      of/address: Don't loop forever in of_find_matching_node_by_address(). · 65a5b34f
      David Daney authored
      commit 3a496b00 upstream.
      
      If the internal call to of_address_to_resource() fails, we end up
      looping forever in of_find_matching_node_by_address().  This can be
      caused by a defective device tree, or calling with an incorrect
      matches argument.
      
      Fix by calling of_find_matching_node() unconditionally at the end of
      the loop.
      Signed-off-by: default avatarDavid Daney <david.daney@cavium.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      65a5b34f
    • Adrien Schildknecht's avatar
      rtlwifi: rtl8192cu: Add new device ID · 461a40ce
      Adrien Schildknecht authored
      commit 1642d09f upstream.
      
      The v2 of NetGear WNA1000M uses a different idProduct: USB ID 0846:9043
      Signed-off-by: default avatarAdrien Schildknecht <adrien+dev@schischi.me>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      461a40ce
    • Jan H. Schönherr's avatar
      sched: Fix cpu_active_mask/cpu_online_mask race · 74686cbf
      Jan H. Schönherr authored
      commit dd9d3843 upstream.
      
      There is a race condition in SMP bootup code, which may result
      in
      
          WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
          workqueue_cpu_up_callback()
      or
          kernel BUG at kernel/smpboot.c:135!
      
      It can be triggered with a bit of luck in Linux guests running
      on busy hosts.
      
      	CPU0                        CPUn
      	====                        ====
      
      	_cpu_up()
      	  __cpu_up()
      				    start_secondary()
      				      set_cpu_online()
      					cpumask_set_cpu(cpu,
      						   to_cpumask(cpu_online_bits));
      	  cpu_notify(CPU_ONLINE)
      	    <do stuff, see below>
      					cpumask_set_cpu(cpu,
      						   to_cpumask(cpu_active_bits));
      
      During the various CPU_ONLINE callbacks CPUn is online but not
      active. Several things can go wrong at that point, depending on
      the scheduling of tasks on CPU0.
      
      Variant 1:
      
        cpu_notify(CPU_ONLINE)
          workqueue_cpu_up_callback()
            rebind_workers()
              set_cpus_allowed_ptr()
      
        This call fails because it requires an active CPU; rebind_workers()
        ends with a warning:
      
          WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
          workqueue_cpu_up_callback()
      
      Variant 2:
      
        cpu_notify(CPU_ONLINE)
          smpboot_thread_call()
            smpboot_unpark_threads()
             ..
              __kthread_unpark()
                __kthread_bind()
                wake_up_state()
                 ..
                  select_task_rq()
                    select_fallback_rq()
      
        The ->wake_cpu of the unparked thread is not allowed, making a call
        to select_fallback_rq() necessary. Then, select_fallback_rq() cannot
        find an allowed, active CPU and promptly resets the allowed CPUs, so
        that the task in question ends up on CPU0.
      
        When those unparked tasks are eventually executed, they run
        immediately into a BUG:
      
          kernel BUG at kernel/smpboot.c:135!
      
      Just changing the order in which the online/active bits are set
      (and adding some memory barriers), would solve the two issues
      above. However, it would change the order of operations back to
      the one before commit 6acbfb96 ("sched: Fix hotplug vs.
      set_cpus_allowed_ptr()"), thus, reintroducing that particular
      problem.
      
      Going further back into history, we have at least the following
      commits touching this topic:
      - commit 2baab4e9 ("sched: Fix select_fallback_rq() vs cpu_active/cpu_online")
      - commit 5fbd036b ("sched: Cleanup cpu_active madness")
      
      Together, these give us the following non-working solutions:
      
        - secondary CPU sets active before online, because active is assumed to
          be a subset of online;
      
        - secondary CPU sets online before active, because the primary CPU
          assumes that an online CPU is also active;
      
        - secondary CPU sets online and waits for primary CPU to set active,
          because it might deadlock.
      
      Commit 875ebe94 ("powerpc/smp: Wait until secondaries are
      active & online") introduces an arch-specific solution to this
      arch-independent problem.
      
      Now, go for a more general solution without explicit waiting and
      simply set active twice: once on the secondary CPU after online
      was set and once on the primary CPU after online was seen.
      
      set_cpus_allowed_ptr()")
      Signed-off-by: default avatarJan H. Schönherr <jschoenh@amazon.de>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Wilson <msw@amazon.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 6acbfb96 ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
      Link: http://lkml.kernel.org/r/1439408156-18840-1-git-send-email-jschoenh@amazon.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      74686cbf
    • Jan Kara's avatar
      xfs: Fix file type directory corruption for btree directories · 112738b6
      Jan Kara authored
      commit 03754234 upstream.
      
      Users have occasionally reported that file type for some directory
      entries is wrong. This mostly happened after updating libraries some
      libraries. After some debugging the problem was traced down to
      xfs_dir2_node_replace(). The function uses args->filetype as a file type
      to store in the replaced directory entry however it also calls
      xfs_da3_node_lookup_int() which will store file type of the current
      directory entry in args->filetype. Thus we fail to change file type of a
      directory entry to a proper type.
      
      Fix the problem by storing new file type in a local variable before
      calling xfs_da3_node_lookup_int().
      Reported-by: default avatarGiacomo Comes <comes@naic.edu>
      Signed-off-by: default avatarJan Kara <jack@suse.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      112738b6
    • Zhang Rui's avatar
      PCI: Disable async suspend/resume for JMicron multi-function SATA/AHCI · a119a132
      Zhang Rui authored
      commit 91f15fb3 upstream.
      
      On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at
      function 1 doesn't work if it is powered on before the SATA controller at
      function 0.  The result is that PATA doesn't work after resume, and we
      print messages like this:
      
        pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3
        irq 17: nobody cared (try booting with the "irqpoll" option)
      
      Async resume was introduced in v3.15 by 76569faa ("PM / sleep:
      Asynchronous threads for resume_noirq").  Prior to that, we powered on
      the functions in order, so this problem shouldn't happen.
      
      e6b7e41c ("ata: Disabling the async PM for JMicron chip 363/361")
      solved the problem for JMicron 361 and 363 devices.  With async suspend
      disabled, we always power on function 0 before function 1.
      
      Barto then reported the same problem with a JMicron 368 (see comment #57 in
      the bugzilla).
      
      Rather than extending the blacklist piecemeal, disable async suspend for
      all JMicron multi-function SATA/PATA/AHCI devices.
      
      This quirk could stay in the ahci and pata_jmicron drivers, but it's likely
      the problem will occur even if pata_jmicron isn't loaded until after the
      suspend/resume.  Making it a PCI quirk ensures that we'll preserve the
      power-on order even if the drivers aren't loaded.
      
      [bhelgaas: changelog, limit to multi-function, limit to IDE/ATA]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551Reported-and-tested-by: default avatarBarto <mister.freeman@laposte.net>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a119a132
    • Stephen Chandler Paul's avatar
      DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd · ebf9d650
      Stephen Chandler Paul authored
      commit 924f92bf upstream.
      
      Most of the time this isn't an issue since hotplugging an adaptor will
      trigger a crtc mode change which in turn, causes the driver to probe
      every DisplayPort for a dpcd. However, in cases where hotplugging
      doesn't cause a mode change (specifically when one unplugs a monitor
      from a DisplayPort connector, then plugs that same monitor back in
      seconds later on the same port without any other monitors connected), we
      never probe for the dpcd before starting the initial link training. What
      happens from there looks like this:
      
      	- GPU has only one monitor connected. It's connected via
      	  DisplayPort, and does not go through an adaptor of any sort.
      
      	- User unplugs DisplayPort connector from GPU.
      
      	- Change in HPD is detected by the driver, we probe every
      	  DisplayPort for a possible connection.
      
      	- Probe the port the user originally had the monitor connected
      	  on for it's dpcd. This fails, and we clear the first (and only
      	  the first) byte of the dpcd to indicate we no longer have a
      	  dpcd for this port.
      
      	- User plugs the previously disconnected monitor back into the
      	  same DisplayPort.
      
      	- radeon_connector_hotplug() is called before everyone else,
      	  and tries to handle the link training. Since only the first
      	  byte of the dpcd is zeroed, the driver is able to complete
      	  link training but does so against the wrong dpcd, causing it
      	  to initialize the link with the wrong settings.
      
      	- Display stays blank (usually), dpcd is probed after the
      	  initial link training, and the driver prints no obvious
      	  messages to the log.
      
      In theory, since only one byte of the dpcd is chopped off (specifically,
      the byte that contains the revision information for DisplayPort), it's
      not entirely impossible that this bug may not show on certain monitors.
      For instance, the only reason this bug was visible on my ASUS PB238
      monitor was due to the fact that this monitor using the enhanced framing
      symbol sequence, the flag for which is ignored if the radeon driver
      thinks that the DisplayPort version is below 1.1.
      Signed-off-by: default avatarStephen Chandler Paul <cpaul@redhat.com>
      Reviewed-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ebf9d650
    • Benjamin Cama's avatar
      ARM: orion5x: fix legacy orion5x IRQ numbers · c1e70dbd
      Benjamin Cama authored
      commit 5be9fc23 upstream.
      
      Since v3.18, attempts to deliver IRQ0 are rejected, breaking orion5x.
      Fix this by increasing all interrupts by one, as did 5d6bed2a for
      dove. Also, force MULTI_IRQ_HANDLER for all orion platforms (including
      dove) as the specific handler is needed to shift back IRQ numbers by
      one.
      
      [gregory.clement@free-electrons.com]: moved the select
      MULTI_IRQ_HANDLER from PLAT_ORION_LEGACY to ARCH_ORION5X as it broke
      the build for dove.
      
      Fixes: a71b092a ("ARM: Convert handle_IRQ to use __handle_domain_irq")
      Signed-off-by: default avatarBenjamin Cama <benoar@dolka.fr>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Tested-by: default avatarDetlef Vollmann <dv@vollmann.ch>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c1e70dbd
    • Vaishali Thakkar's avatar
      ASoC: samsung: Remove redundant arndale_audio_remove · 98065572
      Vaishali Thakkar authored
      commit 14a500fe upstream.
      
      There is no use of snd_soc_unregister_card in remove function
      as devm_snd_soc_register_card in probe function automatically
      handles it. So, remove use of snd_soc_unregister_card and with
      this change remove arndale_audio_remove as it is now redundant.
      Signed-off-by: default avatarVaishali Thakkar <vthakkar1994@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      98065572
    • Filipe Manana's avatar
      Btrfs: check if previous transaction aborted to avoid fs corruption · 32768523
      Filipe Manana authored
      commit 1f9b8c8f upstream.
      
      While we are committing a transaction, it's possible the previous one is
      still finishing its commit and therefore we wait for it to finish first.
      However we were not checking if that previous transaction ended up getting
      aborted after we waited for it to commit, so we ended up committing the
      current transaction which can lead to fs corruption because the new
      superblock can point to trees that have had one or more nodes/leafs that
      were never durably persisted.
      The following sequence diagram exemplifies how this is possible:
      
                CPU 0                                                        CPU 1
      
        transaction N starts
      
        (...)
      
        btrfs_commit_transaction(N)
      
          cur_trans->state = TRANS_STATE_COMMIT_START;
          (...)
          cur_trans->state = TRANS_STATE_COMMIT_DOING;
          (...)
      
          cur_trans->state = TRANS_STATE_UNBLOCKED;
          root->fs_info->running_transaction = NULL;
      
                                                                    btrfs_start_transaction()
                                                                       --> starts transaction N + 1
      
          btrfs_write_and_wait_transaction(trans, root);
            --> starts writing all new or COWed ebs created
                at transaction N
      
                                                                    creates some new ebs, COWs some
                                                                    existing ebs but doesn't COW or
                                                                    deletes eb X
      
                                                                    btrfs_commit_transaction(N + 1)
                                                                      (...)
                                                                      cur_trans->state = TRANS_STATE_COMMIT_START;
                                                                      (...)
                                                                      wait_for_commit(root, prev_trans);
                                                                        --> prev_trans == transaction N
      
          btrfs_write_and_wait_transaction() continues
          writing ebs
             --> fails writing eb X, we abort transaction N
                 and set bit BTRFS_FS_STATE_ERROR on
                 fs_info->fs_state, so no new transactions
                 can start after setting that bit
      
             cleanup_transaction()
               btrfs_cleanup_one_transaction()
                 wakes up task at CPU 1
      
                                                                      continues, doesn't abort because
                                                                      cur_trans->aborted (transaction N + 1)
                                                                      is zero, and no checks for bit
                                                                      BTRFS_FS_STATE_ERROR in fs_info->fs_state
                                                                      are made
      
                                                                      btrfs_write_and_wait_transaction(trans, root);
                                                                        --> succeeds, no errors during writeback
      
                                                                      write_ctree_super(trans, root, 0);
                                                                        --> succeeds
                                                                        --> we have now a superblock that points us
                                                                            to some root that uses eb X, which was
                                                                            never written to disk
      
      In this scenario future attempts to read eb X from disk results in an
      error message like "parent transid verify failed on X wanted Y found Z".
      
      So fix this by aborting the current transaction if after waiting for the
      previous transaction we verify that it was aborted.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Reviewed-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      32768523
    • Nikesh Oswal's avatar
      ASoC: arizona: Fix gain settings of FLL in free-run mode · 0ca1e234
      Nikesh Oswal authored
      commit 1cf5a330 upstream.
      
      The wrong register was used to set the gain of ref loop, when changing
      the FLL output on an active FLL. This patch corrects the offset of the
      gain register.
      Signed-off-by: default avatarNikesh Oswal <Nikesh.Oswal@wolfsonmicro.com>
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0ca1e234
    • Jeff Vander Stoep's avatar
      arm64: kconfig: Move LIST_POISON to a safe value · 9d154612
      Jeff Vander Stoep authored
      commit bf0c4e04 upstream.
      
      Move the poison pointer offset to 0xdead000000000000, a
      recognized value that is not mappable by user-space exploits.
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarThierry Strudel <tstrudel@google.com>
      Signed-off-by: default avatarJeff Vander Stoep <jeffv@google.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9d154612
    • Martin Schwidefsky's avatar
      s390/setup: fix novx parameter · 865e74a3
      Martin Schwidefsky authored
      commit 89b1145e upstream.
      
      The novx parameter disables the vector facility but the HWCAP_S390_VXRS
      bit in the ELf hardware capabilies is always set if the machine has
      the vector facility. If the user space program uses the "vx" string
      in the features field of /proc/cpuinfo to utilize vector instruction
      it will crash if the novx kernel paramter is set.
      
      Convert setup_hwcaps to an arch_initcall and use MACHINE_HAS_VX to
      decide if the HWCAPS_S390_VXRS bit needs to be set.
      Reported-by: default avatarUlrich Weigand <uweigand@de.ibm.com>
      Reviewed-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      865e74a3
    • Jan Kara's avatar
      xfs: Fix xfs_attr_leafblock definition · dfb43f61
      Jan Kara authored
      commit ffeecc52 upstream.
      
      struct xfs_attr_leafblock contains 'entries' array which is declared
      with size 1 altough it can in fact contain much more entries. Since this
      array is followed by further struct members, gcc (at least in version
      4.8.3) thinks that the array has the fixed size of 1 element and thus
      may optimize away all accesses beyond the end of array resulting in
      non-working code. This problem was only observed with userspace code in
      xfsprogs, however it's better to be safe in kernel as well and have
      matching kernel and xfsprogs definitions.
      Signed-off-by: default avatarJan Kara <jack@suse.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      dfb43f61
    • Darrick J. Wong's avatar
      libxfs: readahead of dir3 data blocks should use the read verifier · 10faa3ba
      Darrick J. Wong authored
      commit 2f123bce upstream.
      
      In the dir3 data block readahead function, use the regular read
      verifier to check the block's CRC and spot-check the block contents
      instead of directly calling only the spot-checking routine.  This
      prevents corrupted directory data blocks from being read into the
      kernel, which can lead to garbage ls output and directory loops (if
      say one of the entries contains slashes and other junk).
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      10faa3ba
    • Tyler Hicks's avatar
      eCryptfs: Invalidate dcache entries when lower i_nlink is zero · 9cdbd0db
      Tyler Hicks authored
      commit 5556e7e6 upstream.
      
      Consider eCryptfs dcache entries to be stale when the corresponding
      lower inode's i_nlink count is zero. This solves a problem caused by the
      lower inode being directly modified, without going through the eCryptfs
      mount, leaving stale eCryptfs dentries cached and the eCryptfs inode's
      i_nlink count not being cleared.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Reported-by: default avatarRichard Weinberger <richard@nod.at>
      [ luis: backported to 3.16:
        - use dentry->d_inode instead of d_inode(dentry)
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9cdbd0db
    • Don Zickus's avatar
      HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error · ab0c383e
      Don Zickus authored
      commit 3af4e5a9 upstream.
      
      It was reported that after 10-20 reboots, a usb keyboard plugged
      into a docking station would not work unless it was replugged in.
      
      Using usbmon, it turns out the interrupt URBs were streaming with
      callback errors of -71 for some reason.  The hid-core.c::hid_io_error was
      supposed to retry and then reset, but the reset wasn't really happening.
      
      The check for HID_NO_BANDWIDTH was inverted.  Fix was simple.
      
      Tested by reporter and locally by me by unplugging a keyboard halfway until I
      could recreate a stream of errors but no disconnect.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ab0c383e
    • Shota Suzuki's avatar
      igb: Fix oops caused by missing queue pairing · b5adc116
      Shota Suzuki authored
      commit 72ddef05 upstream.
      
      When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
      set if adapter->rss_queues exceeds half of max_rss_queues in
      igb_init_queue_configuration().
      On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
      queues exceeds half of max_combined in igb_set_channels() when changing
      the number of queues by "ethtool -L".
      In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
      of adapter->msix_entries[], an overflow can occur in
      igb_set_interrupt_capability(), which in turn leads to an oops.
      
      Fix this problem as follows:
       - When changing the number of queues by "ethtool -L", set
         IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
       - When increasing the size of q_vector, reallocate it appropriately.
         (With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)
      
      Another possible way to fix this problem is to cap the queues at its
      initial number, which is the number of the initial online cpus. But this
      is not the optimal way because we cannot increase queues when another
      cpu becomes online.
      
      Note that before commit cd14ef54 ("igb: Change to use statically
      allocated array for MSIx entries"), this problem did not cause oops
      but just made the number of queues become 1 because of entering msi_only
      mode in igb_set_interrupt_capability().
      
      Fixes: 907b7835 ("igb: Add ethtool support to configure number of channels")
      Signed-off-by: default avatarShota Suzuki <suzuki_shota_t3@lab.ntt.co.jp>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b5adc116
    • David Ward's avatar
      c6737836
    • Matthijs Kooijman's avatar
      USB: ftdi_sio: Added custom PID for CustomWare products · ae5c23d9
      Matthijs Kooijman authored
      commit 1fb8dc36 upstream.
      
      CustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex
      products.
      Signed-off-by: default avatarMatthijs Kooijman <matthijs@stdin.nl>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ae5c23d9
    • Philipp Hachtmann's avatar
      USB: symbolserial: Use usb_get_serial_port_data · 7fb281c3
      Philipp Hachtmann authored
      commit 951d3793 upstream.
      
      The driver used usb_get_serial_data(port->serial) which compiled but resulted
      in a NULL pointer being returned (and subsequently used). I did not go deeper
      into this but I guess this is a regression.
      Signed-off-by: default avatarPhilipp Hachtmann <hachti@hachti.de>
      Fixes: a85796ee ("USB: symbolserial: move private-data allocation to
      port_probe")
      Acked-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7fb281c3
    • Peter Chen's avatar
      usb: host: ehci-sys: delete useless bus_to_hcd conversion · dc460de5
      Peter Chen authored
      commit 0521cfd0 upstream.
      
      The ehci platform device's drvdata is the pointer of struct usb_hcd
      already, so we doesn't need to call bus_to_hcd conversion again.
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      dc460de5
    • Kinglong Mee's avatar
      NFS: Fix a NULL pointer dereference of migration recovery ops for v4.2 client · 42a3c62c
      Kinglong Mee authored
      commit 18e3b739 upstream.
      
      ---Steps to Reproduce--
      <nfs-server>
      # cat /etc/exports
      /nfs/referal  *(rw,insecure,no_subtree_check,no_root_squash,crossmnt)
      /nfs/old      *(ro,insecure,subtree_check,root_squash,crossmnt)
      
      <nfs-client>
      # mount -t nfs nfs-server:/nfs/ /mnt/
      # ll /mnt/*/
      
      <nfs-server>
      # cat /etc/exports
      /nfs/referal   *(rw,insecure,no_subtree_check,no_root_squash,crossmnt,refer=/nfs/old/@nfs-server)
      /nfs/old       *(ro,insecure,subtree_check,root_squash,crossmnt)
      # service nfs restart
      
      <nfs-client>
      # ll /mnt/*/    --->>>>> oops here
      
      [ 5123.102925] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [ 5123.103363] IP: [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
      [ 5123.103752] PGD 587b9067 PUD 3cbf5067 PMD 0
      [ 5123.104131] Oops: 0000 [#1]
      [ 5123.104529] Modules linked in: nfsv4(OE) nfs(OE) fscache(E) nfsd(OE) xfs libcrc32c iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev vmw_balloon parport_pc parport i2c_piix4 shpchp auth_rpcgss nfs_acl vmw_vmci lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi serio_raw scsi_transport_spi e1000 mptscsih mptbase ata_generic pata_acpi [last unloaded: nfsd]
      [ 5123.105887] CPU: 0 PID: 15853 Comm: ::1-manager Tainted: G           OE   4.2.0-rc6+ #214
      [ 5123.106358] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
      [ 5123.106860] task: ffff88007620f300 ti: ffff88005877c000 task.ti: ffff88005877c000
      [ 5123.107363] RIP: 0010:[<ffffffffa03ed38b>]  [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
      [ 5123.107909] RSP: 0018:ffff88005877fdb8  EFLAGS: 00010246
      [ 5123.108435] RAX: ffff880053f3bc00 RBX: ffff88006ce6c908 RCX: ffff880053a0d240
      [ 5123.108968] RDX: ffffea0000e6d940 RSI: ffff8800399a0000 RDI: ffff88006ce6c908
      [ 5123.109503] RBP: ffff88005877fe28 R08: ffffffff81c708a0 R09: 0000000000000000
      [ 5123.110045] R10: 00000000000001a2 R11: ffff88003ba7f5c8 R12: ffff880054c55800
      [ 5123.110618] R13: 0000000000000000 R14: ffff880053a0d240 R15: ffff880053a0d240
      [ 5123.111169] FS:  0000000000000000(0000) GS:ffffffff81c27000(0000) knlGS:0000000000000000
      [ 5123.111726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 5123.112286] CR2: 0000000000000000 CR3: 0000000054cac000 CR4: 00000000001406f0
      [ 5123.112888] Stack:
      [ 5123.113458]  ffffea0000e6d940 ffff8800399a0000 00000000000167d0 0000000000000000
      [ 5123.114049]  0000000000000000 0000000000000000 0000000000000000 00000000a7ec82c6
      [ 5123.114662]  ffff88005877fe18 ffffea0000e6d940 ffff8800399a0000 ffff880054c55800
      [ 5123.115264] Call Trace:
      [ 5123.115868]  [<ffffffffa03fb44b>] nfs4_try_migration+0xbb/0x220 [nfsv4]
      [ 5123.116487]  [<ffffffffa03fcb3b>] nfs4_run_state_manager+0x4ab/0x7b0 [nfsv4]
      [ 5123.117104]  [<ffffffffa03fc690>] ? nfs4_do_reclaim+0x510/0x510 [nfsv4]
      [ 5123.117813]  [<ffffffff810a4527>] kthread+0xd7/0xf0
      [ 5123.118456]  [<ffffffff810a4450>] ? kthread_worker_fn+0x160/0x160
      [ 5123.119108]  [<ffffffff816d9cdf>] ret_from_fork+0x3f/0x70
      [ 5123.119723]  [<ffffffff810a4450>] ? kthread_worker_fn+0x160/0x160
      [ 5123.120329] Code: 4c 8b 6a 58 74 17 eb 52 48 8d 55 a8 89 c6 4c 89 e7 e8 4a b5 ff ff 8b 45 b0 85 c0 74 1c 4c 89 f9 48 8b 55 90 48 8b 75 98 48 89 df <41> ff 55 00 3d e8 d8 ff ff 41 89 c6 74 cf 48 8b 4d c8 65 48 33
      [ 5123.121643] RIP  [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
      [ 5123.122308]  RSP <ffff88005877fdb8>
      [ 5123.122942] CR2: 0000000000000000
      
      Fixes: ec011fe8 ("NFS: Introduce a vector of migration recovery ops")
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      42a3c62c
    • Trond Myklebust's avatar
      NFS: nfs_set_pgio_error sometimes misses errors · 7443328c
      Trond Myklebust authored
      commit e9ae58ae upstream.
      
      We should ensure that we always set the pgio_header's error field
      if a READ or WRITE RPC call returns an error. The current code depends
      on 'hdr->good_bytes' always being initialised to a large value, which
      is not always done correctly by callers.
      When this happens, applications may end up missing important errors.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7443328c
    • Max Filippov's avatar
      xtensa: fix kernel register spilling · 5cadfe32
      Max Filippov authored
      commit 77d6273e upstream.
      
      call12 can't be safely used as the first call in the inline function,
      because the compiler does not extend the stack frame of the bounding
      function accordingly, which may result in corruption of local variables.
      
      If a call needs to be done, do call8 first followed by call12.
      
      For pure assembly code in _switch_to increase stack frame size of the
      bounding function.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5cadfe32
    • Ming Lei's avatar
      blk-mq: fix race between timeout and freeing request · 3ea7b22d
      Ming Lei authored
      commit 0048b483 upstream.
      
      Inside timeout handler, blk_mq_tag_to_rq() is called
      to retrieve the request from one tag. This way is obviously
      wrong because the request can be freed any time and some
      fiedds of the request can't be trusted, then kernel oops
      might be triggered[1].
      
      Currently wrt. blk_mq_tag_to_rq(), the only special case is
      that the flush request can share same tag with the request
      cloned from, and the two requests can't be active at the same
      time, so this patch fixes the above issue by updating tags->rqs[tag]
      with the active request(either flush rq or the request cloned
      from) of the tag.
      
      Also blk_mq_tag_to_rq() gets much simplified with this patch.
      
      Given blk_mq_tag_to_rq() is mainly for drivers and the caller must
      make sure the request can't be freed, so in bt_for_each() this
      helper is replaced with tags->rqs[tag].
      
      [1] kernel oops log
      [  439.696220] BUG: unable to handle kernel NULL pointer dereference at 0000000000000158^M
      [  439.697162] IP: [<ffffffff812d89ba>] blk_mq_tag_to_rq+0x21/0x6e^M
      [  439.700653] PGD 7ef765067 PUD 7ef764067 PMD 0 ^M
      [  439.700653] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M
      [  439.700653] Dumping ftrace buffer:^M
      [  439.700653]    (ftrace buffer empty)^M
      [  439.700653] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw^M
      [  439.700653] CPU: 6 PID: 2779 Comm: stress-ng-sigfd Not tainted 4.2.0-rc5-next-20150805+ #265^M
      [  439.730500] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011^M
      [  439.730500] task: ffff880605308000 ti: ffff88060530c000 task.ti: ffff88060530c000^M
      [  439.730500] RIP: 0010:[<ffffffff812d89ba>]  [<ffffffff812d89ba>] blk_mq_tag_to_rq+0x21/0x6e^M
      [  439.730500] RSP: 0018:ffff880819203da0  EFLAGS: 00010283^M
      [  439.730500] RAX: ffff880811b0e000 RBX: ffff8800bb465f00 RCX: 0000000000000002^M
      [  439.730500] RDX: 0000000000000000 RSI: 0000000000000202 RDI: 0000000000000000^M
      [  439.730500] RBP: ffff880819203db0 R08: 0000000000000002 R09: 0000000000000000^M
      [  439.730500] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000202^M
      [  439.730500] R13: ffff880814104800 R14: 0000000000000002 R15: ffff880811a2ea00^M
      [  439.730500] FS:  00007f165b3f5740(0000) GS:ffff880819200000(0000) knlGS:0000000000000000^M
      [  439.730500] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b^M
      [  439.730500] CR2: 0000000000000158 CR3: 00000007ef766000 CR4: 00000000000006e0^M
      [  439.730500] Stack:^M
      [  439.730500]  0000000000000008 ffff8808114eed90 ffff880819203e00 ffffffff812dc104^M
      [  439.755663]  ffff880819203e40 ffffffff812d9f5e 0000020000000000 ffff8808114eed80^M
      [  439.755663] Call Trace:^M
      [  439.755663]  <IRQ> ^M
      [  439.755663]  [<ffffffff812dc104>] bt_for_each+0x6e/0xc8^M
      [  439.755663]  [<ffffffff812d9f5e>] ? blk_mq_rq_timed_out+0x6a/0x6a^M
      [  439.755663]  [<ffffffff812d9f5e>] ? blk_mq_rq_timed_out+0x6a/0x6a^M
      [  439.755663]  [<ffffffff812dc1b3>] blk_mq_tag_busy_iter+0x55/0x5e^M
      [  439.755663]  [<ffffffff812d88b4>] ? blk_mq_bio_to_request+0x38/0x38^M
      [  439.755663]  [<ffffffff812d8911>] blk_mq_rq_timer+0x5d/0xd4^M
      [  439.755663]  [<ffffffff810a3e10>] call_timer_fn+0xf7/0x284^M
      [  439.755663]  [<ffffffff810a3d1e>] ? call_timer_fn+0x5/0x284^M
      [  439.755663]  [<ffffffff812d88b4>] ? blk_mq_bio_to_request+0x38/0x38^M
      [  439.755663]  [<ffffffff810a46d6>] run_timer_softirq+0x1ce/0x1f8^M
      [  439.755663]  [<ffffffff8104c367>] __do_softirq+0x181/0x3a4^M
      [  439.755663]  [<ffffffff8104c76e>] irq_exit+0x40/0x94^M
      [  439.755663]  [<ffffffff81031482>] smp_apic_timer_interrupt+0x33/0x3e^M
      [  439.755663]  [<ffffffff815559a4>] apic_timer_interrupt+0x84/0x90^M
      [  439.755663]  <EOI> ^M
      [  439.755663]  [<ffffffff81554350>] ? _raw_spin_unlock_irq+0x32/0x4a^M
      [  439.755663]  [<ffffffff8106a98b>] finish_task_switch+0xe0/0x163^M
      [  439.755663]  [<ffffffff8106a94d>] ? finish_task_switch+0xa2/0x163^M
      [  439.755663]  [<ffffffff81550066>] __schedule+0x469/0x6cd^M
      [  439.755663]  [<ffffffff8155039b>] schedule+0x82/0x9a^M
      [  439.789267]  [<ffffffff8119b28b>] signalfd_read+0x186/0x49a^M
      [  439.790911]  [<ffffffff8106d86a>] ? wake_up_q+0x47/0x47^M
      [  439.790911]  [<ffffffff811618c2>] __vfs_read+0x28/0x9f^M
      [  439.790911]  [<ffffffff8117a289>] ? __fget_light+0x4d/0x74^M
      [  439.790911]  [<ffffffff811620a7>] vfs_read+0x7a/0xc6^M
      [  439.790911]  [<ffffffff8116292b>] SyS_read+0x49/0x7f^M
      [  439.790911]  [<ffffffff81554c17>] entry_SYSCALL_64_fastpath+0x12/0x6f^M
      [  439.790911] Code: 48 89 e5 e8 a9 b8 e7 ff 5d c3 0f 1f 44 00 00 55 89
      f2 48 89 e5 41 54 41 89 f4 53 48 8b 47 60 48 8b 1c d0 48 8b 7b 30 48 8b
      53 38 <48> 8b 87 58 01 00 00 48 85 c0 75 09 48 8b 97 88 0c 00 00 eb 10
      ^M
      [  439.790911] RIP  [<ffffffff812d89ba>] blk_mq_tag_to_rq+0x21/0x6e^M
      [  439.790911]  RSP <ffff880819203da0>^M
      [  439.790911] CR2: 0000000000000158^M
      [  439.790911] ---[ end trace d40af58949325661 ]---^M
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [ kamal: backport to 3.19-stable: no bt_tags_for_each() ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3ea7b22d
    • Ming Lei's avatar
      blk-mq: fix buffer overflow when reading sysfs file of 'pending' · e38a9c2f
      Ming Lei authored
      commit 596f5aad upstream.
      
      There may be lots of pending requests so that the buffer of PAGE_SIZE
      can't hold them at all.
      
      One typical example is scsi-mq, the queue depth(.can_queue) of
      scsi_host and blk-mq is quite big but scsi_device's queue_depth
      is a bit small(.cmd_per_lun), then it is quite easy to have lots
      of pending requests in hw queue.
      
      This patch fixes the following warning and the related memory
      destruction.
      
      [  359.025101] fill_read_buffer: blk_mq_hw_sysfs_show+0x0/0x7d returned bad count^M
      [  359.055595] irq event stamp: 15537^M
      [  359.055606] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M
      [  359.055614] Dumping ftrace buffer:^M
      [  359.055660]    (ftrace buffer empty)^M
      [  359.055672] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw^M
      [  359.055678] CPU: 4 PID: 21631 Comm: stress-ng-sysfs Not tainted 4.2.0-rc5-next-20150805 #434^M
      [  359.055679] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011^M
      [  359.055682] task: ffff8802161cc000 ti: ffff88021b4a8000 task.ti: ffff88021b4a8000^M
      [  359.055693] RIP: 0010:[<ffffffff811541c5>]  [<ffffffff811541c5>] __kmalloc+0xe8/0x152^M
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e38a9c2f
    • Eric Sandeen's avatar
      ext4: don't manipulate recovery flag when freezing no-journal fs · e7eae1d1
      Eric Sandeen authored
      commit c642dc9e upstream.
      
      At some point along this sequence of changes:
      
      f6e63f90 ext4: fold ext4_nojournal_sops into ext4_sops
      bb044576 ext4: support freezing ext2 (nojournal) file systems
      9ca92389 ext4: Use separate super_operations structure for no_journal filesystems
      
      ext4 started setting needs_recovery on filesystems without journals
      when they are unfrozen.  This makes no sense, and in fact confuses
      blkid to the point where it doesn't recognize the filesystem at all.
      
      (freeze ext2; unfreeze ext2; run blkid; see no output; run dumpe2fs,
      see needs_recovery set on fs w/ no journal).
      
      To fix this, don't manipulate the INCOMPAT_RECOVER feature on
      filesystems without journals.
      Reported-by: default avatarStu Mark <smark@datto.com>
      Reviewed-by: default avatarJan Kara <jack@suse.com>
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e7eae1d1
    • Ian Abbott's avatar
      staging: comedi: adl_pci7x3x: fix digital output on PCI-7230 · af848985
      Ian Abbott authored
      commit ad83dbd9 upstream.
      
      The "adl_pci7x3x" driver replaced the "adl_pci7230" and "adl_pci7432"
      drivers in commits 8f567c37 ("staging: comedi: new adl_pci7x3x
      driver") and 657f77d1 ("staging: comedi: remove adl_pci7230 and
      adl_pci7432 drivers").  Although the new driver code agrees with the
      user manuals for the respective boards, digital outputs stopped working
      on the PCI-7230.  This has 16 digital output channels and the previous
      adl_pci7230 driver shifted the 16 bit output state left by 16 bits
      before writing to the hardware register.  The new adl_pci7x3x driver
      doesn't do that.  Fix it in `adl_pci7x3x_do_insn_bits()` by checking
      for the special case of the subdevice having only 16 channels and
      duplicating the 16 bit output state into both halves of the 32-bit
      register.  That should work both for what the board actually does and
      for what the user manual says it should do.
      
      Fixes: 8f567c37 ("staging: comedi: new adl_pci7x3x driver")
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      af848985
    • Maciej S. Szmigiero's avatar
      serial: 8250: bind to ALi Fast Infrared Controller (ALI5123) · 40eced5d
      Maciej S. Szmigiero authored
      commit 1d700277 upstream.
      
      This way this device can be used with irtty-sir -
      at least on Toshiba Satellite A20-S103 it is not configured by default
      and needs PNP activation before it starts to respond on I/O ports.
      
      This device has actually its own driver (ali-ircc),
      but this driver seems to be non-functional for a very long time
      (see http://permalink.gmane.org/gmane.linux.irda.general/484
      http://permalink.gmane.org/gmane.network.protocols.obex.openobex.user/943
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535070 ).
      Signed-off-by: default avatarMaciej Szmigiero <mail@maciej.szmigiero.name>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      40eced5d