1. 03 Jun, 2016 36 commits
    • Brian Bloniarz's avatar
      Fix OpenSSH pty regression on close · 29a7543e
      Brian Bloniarz authored
      [ Upstream commit 0f40fbbc ]
      
      OpenSSH expects the (non-blocking) read() of pty master to return
      EAGAIN only if it has received all of the slave-side output after
      it has received SIGCHLD. This used to work on pre-3.12 kernels.
      
      This fix effectively forces non-blocking read() and poll() to
      block for parallel i/o to complete for all ttys. It also unwinds
      these changes:
      
      1) f8747d4a
         tty: Fix pty master read() after slave closes
      
      2) 52bce7f8
         pty, n_tty: Simplify input processing on final close
      
      3) 1a48632f
         pty: Fix input race when closing
      
      Inspired by analysis and patch from Marc Aurele La France <tsi@tuyoix.net>
      Reported-by: default avatarVolth <openssh@volth.com>
      Reported-by: default avatarMarc Aurele La France <tsi@tuyoix.net>
      BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52
      BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492Signed-off-by: default avatarBrian Bloniarz <brian.bloniarz@gmail.com>
      Reviewed-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      29a7543e
    • Matthias Schiffer's avatar
      MIPS: ath79: make bootconsole wait for both THRE and TEMT · d46be343
      Matthias Schiffer authored
      [ Upstream commit f5b556c9 ]
      
      This makes the ath79 bootconsole behave the same way as the generic 8250
      bootconsole.
      
      Also waiting for TEMT (transmit buffer is empty) instead of just THRE
      (transmit buffer is not full) ensures that all characters have been
      transmitted before the real serial driver starts reconfiguring the serial
      controller (which would sometimes result in garbage being transmitted.)
      This change does not cause a visible performance loss.
      
      In addition, this seems to fix a hang observed in certain configurations on
      many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.
      
      A more complete follow-up patch will disable 8250 autoconfig for ath79
      altogether (the serial controller is detected as a 16550A, which is not
      fully compatible with the ath79 serial, and the autoconfig may lead to
      undefined behavior on ath79.)
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatthias Schiffer <mschiffer@universe-factory.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d46be343
    • Theodore Ts'o's avatar
      ext4: clean up error handling when orphan list is corrupted · e0934da7
      Theodore Ts'o authored
      [ Upstream commit 7827a7f6 ]
      
      Instead of just printing warning messages, if the orphan list is
      corrupted, declare the file system is corrupted.  If there are any
      reserved inodes in the orphaned inode list, declare the file system
      corrupted and stop right away to avoid doing more potential damage to
      the file system.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e0934da7
    • Theodore Ts'o's avatar
      ext4: fix hang when processing corrupted orphaned inode list · 06c6dcb8
      Theodore Ts'o authored
      [ Upstream commit c9eb13a9 ]
      
      If the orphaned inode list contains inode #5, ext4_iget() returns a
      bad inode (since the bootloader inode should never be referenced
      directly).  Because of the bad inode, we end up processing the inode
      repeatedly and this hangs the machine.
      
      This can be reproduced via:
      
         mke2fs -t ext4 /tmp/foo.img 100
         debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
         mount -o loop /tmp/foo.img /mnt
      
      (But don't do this if you are using an unpatched kernel if you care
      about the system staying functional.  :-)
      
      This bug was found by the port of American Fuzzy Lop into the kernel
      to find file system problems[1].  (Since it *only* happens if inode #5
      shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
      surprising that AFL needed two hours before it found it.)
      
      [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf
      
      Cc: stable@vger.kernel.org
      Reported by: Vegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      06c6dcb8
    • Raghava Aditya Renukunta's avatar
      aacraid: Fix for KDUMP driver hang · bb3412ec
      Raghava Aditya Renukunta authored
      [ Upstream commit 78cbccd3 ]
      
      When KDUMP is triggered the driver first talks to the firmware in INTX
      mode, but the adapter firmware is still in MSIX mode. Therefore the first
      driver command hangs since the driver is waiting for an INTX response and
      firmware gives a MSIX response. If when the OS is installed on a RAID
      drive created by the adapter KDUMP will hang since the driver does not
      receive a response in sync mode.
      
      Fixed by: Change the firmware to INTX mode if it is in MSIX mode before
      sending the first sync command.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRaghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      bb3412ec
    • Raghava Aditya Renukunta's avatar
      aacraid: Fix for aac_command_thread hang · ca7bb254
      Raghava Aditya Renukunta authored
      [ Upstream commit fc4bf75e ]
      
      Typically under error conditions, it is possible for aac_command_thread()
      to miss the wakeup from kthread_stop() and go back to sleep, causing it
      to hang aac_shutdown.
      
      In the observed scenario, the adapter is not functioning correctly and so
      aac_fib_send() never completes (or time-outs depending on how it was
      called). Shortly after aac_command_thread() starts it performs
      aac_fib_send(SendHostTime) which hangs. When aac_probe_one
      /aac_get_adapter_info send time outs, kthread_stop is called which breaks
      the command thread out of it's hang.
      
      The code will still go back to sleep in schedule_timeout() without
      checking kthread_should_stop() so it causes aac_probe_one to hang until
      the schedule_timeout() which is 30 minutes.
      
      Fixed by: Adding another kthread_should_stop() before schedule_timeout()
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRaghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ca7bb254
    • Raghava Aditya Renukunta's avatar
      aacraid: Relinquish CPU during timeout wait · e452f738
      Raghava Aditya Renukunta authored
      [ Upstream commit 07beca2b ]
      
      aac_fib_send has a special function case for initial commands during
      driver initialization using wait < 0(pseudo sync mode). In this case,
      the command does not sleep but rather spins checking for timeout.This
      loop is calls cpu_relax() in an attempt to allow other processes/threads
      to use the CPU, but this function does not relinquish the CPU and so the
      command will hog the processor. This was observed in a KDUMP
      "crashkernel" and that prevented the "command thread" (which is
      responsible for completing the command from being timed out) from
      starting because it could not get the CPU.
      
      Fixed by replacing "cpu_relax()" call with "schedule()"
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRaghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e452f738
    • Marc Zyngier's avatar
      arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables · 660cd223
      Marc Zyngier authored
      [ Upstream commit d4b9e079 ]
      
      The ARM architecture mandates that when changing a page table entry
      from a valid entry to another valid entry, an invalid entry is first
      written, TLB invalidated, and only then the new entry being written.
      
      The current code doesn't respect this, directly writing the new
      entry and only then invalidating TLBs. Let's fix it up.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      660cd223
    • H Hartley Sweeten's avatar
      staging: comedi: das1800: fix possible NULL dereference · 788da6ee
      H Hartley Sweeten authored
      [ Upstream commit d375278d ]
      
      DMA is optional with this driver. If it was not enabled the devpriv->dma
      pointer will be NULL.
      
      Fix the possible NULL pointer dereference when trying to disable the DMA
      channels in das1800_ai_cancel() and tidy up the comments to fix the
      checkpatch.pl issues:
      WARNING: line over 80 characters
      
      It's probably harmless in das1800_ai_setup_dma() because the 'desc' pointer
      will not be used if DMA is disabled but fix it there also.
      
      Fixes: 99dfc335 ("staging: comedi: das1800: remove depends on ISA_DMA_API limitation")
      Cc: <stable@vger.kernel.org> # 4.0+
      Signed-off-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Reviewed-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      788da6ee
    • Jiri Slaby's avatar
      TTY: n_gsm, fix false positive WARN_ON · 14023eff
      Jiri Slaby authored
      [ Upstream commit d175feca ]
      
      Dmitry reported, that the current cleanup code in n_gsm can trigger a
      warning:
      WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0()
      ...
      Call Trace:
      ...
       [<ffffffff81247ab9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:490
       [<ffffffff828d0456>] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048
       [<ffffffff828d4d87>] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386
       [<ffffffff828b9078>] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447
       [<ffffffff828b973a>] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567
       [<     inline     >] tiocsetd drivers/tty/tty_io.c:2650
       [<ffffffff828a14ea>] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883
      ...
      
      But this is a legal path when open fails to find a space in the
      gsm_mux array and tries to clean up. So make it a standard test
      instead of a warning.
      Reported-by: default avatar"Dmitry Vyukov" <dvyukov@google.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com
      Fixes: 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      14023eff
    • David Müller's avatar
      serial: 8250_pci: fix divide error bug if baud rate is 0 · c91d8c2d
      David Müller authored
      [ Upstream commit 6f210c18 ]
      
      Since commit 21947ba6 ("serial: 8250_pci: replace switch-case by
      formula"), the 8250 driver crashes in the byt_set_termios() function
      with a divide error. This is caused by the fact that a baud rate of 0 (B0)
      is not handled properly. Fix it by falling back to B9600 in this case.
      Signed-off-by: default avatarDavid Müller <d.mueller@elsoft.ch>
      Fixes: 21947ba6 ("serial: 8250_pci: replace switch-case by formula")
      Cc: stable@vger.kernel.org
      Suggested-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c91d8c2d
    • Chris Bainbridge's avatar
      usb: core: hub: hub_port_init lock controller instead of bus · 3afbd3e3
      Chris Bainbridge authored
      [ Upstream commit feb26ac3 ]
      
      The XHCI controller presents two USB buses to the system - one for USB2
      and one for USB3. The hub init code (hub_port_init) is reentrant but
      only locks one bus per thread, leading to a race condition failure when
      two threads attempt to simultaneously initialise a USB2 and USB3 device:
      
      [    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
      [   13.183701] usb 3-3: device descriptor read/all, error -110
      
      On a test system this failure occurred on 6% of all boots.
      
      The call traces at the point of failure are:
      
      Call Trace:
       [<ffffffff81b9bab7>] schedule+0x37/0x90
       [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
       [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
       [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
       [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
       [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Call Trace:
       [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
       [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
       [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
       [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Which results from the two call chains:
      
      hub_port_init
       usb_get_device_descriptor
        usb_get_descriptor
         usb_control_msg
          usb_internal_control_msg
           usb_start_wait_urb
            usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
      
      hub_port_init
       hub_set_address
        xhci_address_device
         xhci_setup_device
      
      Mathias Nyman explains the current behaviour violates the XHCI spec:
      
       hub_port_reset() will end up moving the corresponding xhci device slot
       to default state.
      
       As hub_port_reset() is called several times in hub_port_init() it
       sounds reasonable that we could end up with two threads having their
       xhci device slots in default state at the same time, which according to
       xhci 4.5.3 specs still is a big no no:
      
       "Note: Software shall not transition more than one Device Slot to the
        Default State at a time"
      
       So both threads fail at their next task after this.
       One fails to read the descriptor, and the other fails addressing the
       device.
      
      Fix this in hub_port_init by locking the USB controller (instead of an
      individual bus) to prevent simultaneous initialisation of both buses.
      
      Fixes: 638139eb ("usb: hub: allow to process more usb hub events in parallel")
      Link: https://lkml.org/lkml/2016/2/8/312
      Link: https://lkml.org/lkml/2016/2/4/748Signed-off-by: default avatarChris Bainbridge <chris.bainbridge@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      3afbd3e3
    • Luke Dashjr's avatar
      btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl · 7ac47d24
      Luke Dashjr authored
      [ Upstream commit 4c63c245 ]
      
      32-bit ioctl uses these rather than the regular FS_IOC_* versions. They can
      be handled in btrfs using the same code. Without this, 32-bit {ch,ls}attr
      fail.
      Signed-off-by: default avatarLuke Dashjr <luke-jr+git@utopios.org>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7ac47d24
    • Andrew Jeffery's avatar
      pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range · 93ddb49f
      Andrew Jeffery authored
      [ Upstream commit 71324fdc ]
      
      The range is registered into a linked list which can be referenced
      throughout the lifetime of the driver. Ensure the range's memory is useful
      for the same lifetime by adding it to the driver's private data structure.
      
      The bug was introduced in the driver's initial commit, which was present in
      v3.10.
      
      Fixes: f0b9a7e5 ("pinctrl: exynos5440: add pinctrl driver for Samsung EXYNOS5440 SoC")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndrew Jeffery <andrew@aj.id.au>
      Acked-by: default avatarTomasz Figa <tomasz.figa@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      93ddb49f
    • Vittorio Gambaletta (VittGam)'s avatar
      ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. · a774710f
      Vittorio Gambaletta (VittGam) authored
      [ Upstream commit 0f9edcdd ]
      
      The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
      (active high instead of active low).
      
      The same PCI Subsystem ID is used by both cards, which are based on
      the same Atheros MB92 design.
      
      Cc: <linux-wireless@vger.kernel.org>
      Cc: <ath9k-devel@qca.qualcomm.com>
      Cc: <ath9k-devel@lists.ath9k.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a774710f
    • Vittorio Gambaletta (VittGam)'s avatar
      ath9k: Add a module parameter to invert LED polarity. · d24f503d
      Vittorio Gambaletta (VittGam) authored
      [ Upstream commit cd84042c ]
      
      The LED can be active high instead of active low on some hardware.
      
      Add the led_active_high module parameter. It defaults to -1 to obey
      platform data as before.
      
      Setting the parameter to 1 or 0 will force the LED respectively
      active high or active low.
      
      Cc: <linux-wireless@vger.kernel.org>
      Cc: <ath9k-devel@qca.qualcomm.com>
      Cc: <ath9k-devel@lists.ath9k.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d24f503d
    • Krzysztof Kozlowski's avatar
      crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks · 6be9e6ec
      Krzysztof Kozlowski authored
      [ Upstream commit 79152e8d ]
      
      The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
      testing 8 kB size blocks:
      
      	$ sudo modprobe tcrypt sec=1 mode=500
      	testing speed of async ecb(aes) (ecb-aes-s5p) encryption
      	test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes)
      	test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes)
      	test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes)
      	test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes)
      	test 4 (128 bit key, 8192 byte blocks):
      
      This was caused by a race issue of missed BRDMA_DONE ("Block cipher
      Receiving DMA") interrupt. Device starts processing the data in DMA mode
      immediately after setting length of DMA block: receiving (FCBRDMAL) or
      transmitting (FCBTDMAL). The driver sets these lengths from interrupt
      handler through s5p_set_dma_indata() function (or xxx_setdata()).
      
      However the interrupt handler was first dealing with receive buffer
      (dma-unmap old, dma-map new, set receive block length which starts the
      operation), then with transmit buffer and finally was clearing pending
      interrupts (FCINTPEND). Because of the time window between setting
      receive buffer length and clearing pending interrupts, the operation on
      receive buffer could end already and driver would miss new interrupt.
      
      User manual for Exynos5422 confirms in example code that setting DMA
      block lengths should be the last operation.
      
      The tcrypt hang could be also observed in following blocked-task dmesg:
      
      INFO: task modprobe:258 blocked for more than 120 seconds.
            Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      modprobe        D c06b09d8     0   258    256 0x00000000
      [<c06b09d8>] (__schedule) from [<c06b0f24>] (schedule+0x40/0xac)
      [<c06b0f24>] (schedule) from [<c06b49f8>] (schedule_timeout+0x124/0x178)
      [<c06b49f8>] (schedule_timeout) from [<c06b17fc>] (wait_for_common+0xb8/0x144)
      [<c06b17fc>] (wait_for_common) from [<bf0013b8>] (test_acipher_speed+0x49c/0x740 [tcrypt])
      [<bf0013b8>] (test_acipher_speed [tcrypt]) from [<bf003e8c>] (do_test+0x2240/0x30ec [tcrypt])
      [<bf003e8c>] (do_test [tcrypt]) from [<bf008048>] (tcrypt_mod_init+0x48/0xa4 [tcrypt])
      [<bf008048>] (tcrypt_mod_init [tcrypt]) from [<c010177c>] (do_one_initcall+0x3c/0x16c)
      [<c010177c>] (do_one_initcall) from [<c0191ff0>] (do_init_module+0x5c/0x1ac)
      [<c0191ff0>] (do_init_module) from [<c0185610>] (load_module+0x1a30/0x1d08)
      [<c0185610>] (load_module) from [<c0185ab0>] (SyS_finit_module+0x8c/0x98)
      [<c0185ab0>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)
      
      Fixes: a49e490c ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6be9e6ec
    • Krzysztof Kozlowski's avatar
      crypto: s5p-sss - Remove useless hash interrupt handler · cc706ae1
      Krzysztof Kozlowski authored
      [ Upstream commit 55124425 ]
      
      Beside regular feed control interrupt, the driver requires also hash
      interrupt for older SoCs (samsung,s5pv210-secss). However after
      requesting it, the interrupt handler isn't doing anything with it, not
      even clearing the hash interrupt bit.
      
      Driver does not provide hash functions so it is safe to remove the hash
      interrupt related code and to not require the interrupt in Device Tree.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      cc706ae1
    • Ulf Hansson's avatar
      PM / Runtime: Fix error path in pm_runtime_force_resume() · dae205d1
      Ulf Hansson authored
      [ Upstream commit 0ae3aeef ]
      
      As pm_runtime_set_active() may fail because the device's parent isn't
      active, we can end up executing the ->runtime_resume() callback for the
      device when it isn't allowed.
      
      Fix this by invoking pm_runtime_set_active() before running the callback
      and let's also deal with the error code.
      
      Fixes: 37f20416 (PM: Add pm_runtime_suspend|resume_force functions)
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      dae205d1
    • Hari Bathini's avatar
      powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel · b9a5eef0
      Hari Bathini authored
      [ Upstream commit 8ed8ab40 ]
      
      Some of the interrupt vectors on 64-bit POWER server processors are only
      32 bytes long (8 instructions), which is not enough for the full
      first-level interrupt handler. For these we need to branch to an
      out-of-line (OOL) handler. But when we are running a relocatable kernel,
      interrupt vectors till __end_interrupts marker are copied down to real
      address 0x100. So, branching to labels (ie. OOL handlers) outside this
      section must be handled differently (see LOAD_HANDLER()), considering
      relocatable kernel, which would need at least 4 instructions.
      
      However, branching from interrupt vector means that we corrupt the
      CFAR (come-from address register) on POWER7 and later processors as
      mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions)
      that contains the part up to the point where the CFAR is saved in the
      PACA should be part of the short interrupt vectors before we branch out
      to OOL handlers.
      
      But as mentioned already, there are interrupt vectors on 64-bit POWER
      server processors that are only 32 bytes long (like vectors 0x4f00,
      0x4f20, etc.), which cannot accomodate the above two cases at the same
      time owing to space constraint. Currently, in these interrupt vectors,
      we simply branch out to OOL handlers, without using LOAD_HANDLER(),
      which leaves us vulnerable when running a relocatable kernel (eg. kdump
      case). While this has been the case for sometime now and kdump is used
      widely, we were fortunate not to see any problems so far, for three
      reasons:
      
        1. In almost all cases, production kernel (relocatable) is used for
           kdump as well, which would mean that crashed kernel's OOL handler
           would be at the same place where we end up branching to, from short
           interrupt vector of kdump kernel.
        2. Also, OOL handler was unlikely the reason for crash in almost all
           the kdump scenarios, which meant we had a sane OOL handler from
           crashed kernel that we branched to.
        3. On most 64-bit POWER server processors, page size is large enough
           that marking interrupt vector code as executable (see commit
           429d2e83) leads to marking OOL handler code from crashed kernel,
           that sits right below interrupt vector code from kdump kernel, as
           executable as well.
      
      Let us fix this by moving the __end_interrupts marker down past OOL
      handlers to make sure that we also copy OOL handlers to real address
      0x100 when running a relocatable kernel.
      
      This fix has been tested successfully in kdump scenario, on an LPAR with
      4K page size by using different default/production kernel and kdump
      kernel.
      
      Also tested by manually corrupting the OOL handlers in the first kernel
      and then kdump'ing, and then causing the OOL handlers to fire - mpe.
      
      Fixes: c1fb6816 ("powerpc: Add relocation on exception vector handlers")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHari Bathini <hbathini@linux.vnet.ibm.com>
      Signed-off-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b9a5eef0
    • Takashi Iwai's avatar
      Bluetooth: vhci: Fix race at creating hci device · 599a6fc3
      Takashi Iwai authored
      [ Upstream commit c7c999cb ]
      
      hci_vhci driver creates a hci device object dynamically upon each
      HCI_VENDOR_PKT write.  Although it checks the already created object
      and returns an error, it's still racy and may build multiple hci_dev
      objects concurrently when parallel writes are performed, as the device
      tracks only a single hci_dev object.
      
      This patch introduces a mutex to protect against the concurrent device
      creations.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      599a6fc3
    • Akshay Bhat's avatar
      hwmon: (ads7828) Enable internal reference · ef83ef60
      Akshay Bhat authored
      [ Upstream commit 7a18afe8 ]
      
      On ads7828 the internal reference defaults to off upon power up. When
      using internal reference, it needs to be turned on and the voltage needs
      to settle before normal conversion cycle can be started. Hence perform a
      dummy read in the probe to enable the internal reference allowing the
      voltage to settle before performing a normal read.
      
      Without this fix, the first read from the ADC when using internal
      reference always returns incorrect data.
      Signed-off-by: default avatarAkshay Bhat <akshay.bhat@timesys.com>
      Cc: stable@vger.kernel.org # v4.1+
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ef83ef60
    • Michal Nazarewicz's avatar
      usb: f_mass_storage: test whether thread is running before starting another · f5a300ce
      Michal Nazarewicz authored
      [ Upstream commit f78bbcae ]
      
      When binding the function to usb_configuration, check whether the thread
      is running before starting another one.  Without that, when function
      instance is added to multiple configurations, fsg_bing starts multiple
      threads with all but the latest one being forgotten by the driver.  This
      leads to obvious thread leaks, possible lockups when trying to halt the
      machine and possible more issues.
      
      This fixes issues with legacy/multi¹ gadget as well as configfs gadgets
      when mass_storage function is added to multiple configurations.
      
      This change also simplifies API since the legacy gadgets no longer need
      to worry about starting the thread by themselves (which was where bug
      in legacy/multi was in the first place).
      
      N.B., this patch doesn’t address adding single mass_storage function
      instance to a single configuration twice.  Thankfully, there’s no
      legitimate reason for such setup plus, if I’m not mistaken, configfs
      gadget doesn’t even allow it to be expressed.
      
      ¹ I have no example failure though.  Conclusion that legacy/multi has
        a bug is based purely on me reading the code.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Tested-by: default avatarIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f5a300ce
    • Krzysztof Opasiak's avatar
      usb: gadget: mass_storage: Use static array for luns · 799f55d2
      Krzysztof Opasiak authored
      [ Upstream commit dd02ea5a ]
      
      This patch replace dynamicly allocated luns array with static one.
      This simplifies the code of mass storage function and modules.
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      799f55d2
    • Krzysztof Opasiak's avatar
      usb: gadget: mass_storage: Fix freeing luns sysfs implementation · a27b3984
      Krzysztof Opasiak authored
      [ Upstream commit 5542f58c ]
      
      Use device_is_registered() instad of sysfs flag to determine if
      we should free sysfs representation of particular LUN.
      
      sysfs flag in fsg common determines if luns attributes should be
      exposed using sysfs. This flag is used when creating and freeing
      luns. Unfortunately there is no guarantee that this flag will not
      be changed between creation and removal of particular LUN. Especially
      because of lun.0 which is created during allocating instance of
      function. This may lead to resource leak or NULL pointer dereference:
      
      [   62.539925] Unable to handle kernel NULL pointer dereference at virtual address 00000044
      [   62.548014] pgd = ec994000
      [   62.550679] [00000044] *pgd=6d7be831, *pte=00000000, *ppte=00000000
      [   62.556933] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      [   62.562310] Modules linked in: g_mass_storage(+)
      [   62.566916] CPU: 2 PID: 613 Comm: insmod Not tainted 4.2.0-rc4-00077-ge29ee91-dirty #125
      [   62.574984] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [   62.581061] task: eca56e80 ti: eca76000 task.ti: eca76000
      [   62.586450] PC is at kernfs_find_ns+0x8/0xe8
      [   62.590698] LR is at kernfs_find_and_get_ns+0x30/0x48
      [   62.595732] pc : [<c01277c0>]    lr : [<c0127b88>]    psr: 40010053
      [   62.595732] sp : eca77c40  ip : eca77c38  fp : 000008c1
      [   62.607187] r10: 00000001  r9 : c0082f38  r8 : ed41ce40
      [   62.612395] r7 : c05c1484  r6 : 00000000  r5 : 00000000  r4 : c0814488
      [   62.618904] r3 : 00000000  r2 : 00000000  r1 : c05c1484  r0 : 00000000
      [   62.625417] Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment user
      [   62.632620] Control: 10c5387d  Table: 6c99404a  DAC: 00000015
      [   62.638348] Process insmod (pid: 613, stack limit = 0xeca76210)
      [   62.644251] Stack: (0xeca77c40 to 0xeca78000)
      [   62.648594] 7c40: c0814488 00000000 00000000 c05c1484 ed41ce40 c0127b88 00000000 c0824888
      [   62.656753] 7c60: ed41d038 ed41d030 ed41d000 c012af4c 00000000 c0824858 ed41d038 c02e3314
      [   62.664912] 7c80: ed41d030 00000000 ed41ce04 c02d9e8c c070eda8 eca77cb4 000008c1 c058317c
      [   62.673071] 7ca0: 000008c1 ed41d030 ed41ce00 ed41ce04 ed41d000 c02da044 ed41cf48 c0375870
      [   62.681230] 7cc0: ed9d3c04 ed9d3c00 ed52df80 bf000940 fffffff0 c03758f4 c03758c0 00000000
      [   62.689389] 7ce0: bf000564 c03614e0 ed9d3c04 bf000194 c0082f38 00000001 00000000 c0000100
      [   62.697548] 7d00: c0814488 c0814488 c086b1dc c05893a8 00000000 ed7e8320 00000000 c0128b88
      [   62.705707] 7d20: ed8a6b40 00000000 00000000 ed410500 ed8a6b40 c0594818 ed7e8320 00000000
      [   62.713867] 7d40: 00000000 c0129f20 00000000 c082c444 ed8a6b40 c012a684 00001000 00000000
      [   62.722026] 7d60: c0594818 c082c444 00000000 00000000 ed52df80 ed52df80 00000000 00000000
      [   62.730185] 7d80: 00000000 00000000 00000001 00000002 ed8e9b70 ed52df80 bf0006d0 00000000
      [   62.738345] 7da0: ed8e9b70 ed410500 ed618340 c036129c ed8c1c00 bf0006d0 c080b158 ed8c1c00
      [   62.746504] 7dc0: bf0006d0 c080b158 ed8c1c08 ed410500 c0082f38 ed618340 000008c1 c03640ac
      [   62.754663] 7de0: 00000000 bf0006d0 c082c8dc c080b158 c080b158 c03642d4 00000000 bf003000
      [   62.762822] 7e00: 00000000 c0009784 00000000 00000001 00000000 c05849b0 00000002 ee7ab780
      [   62.770981] 7e20: 00000002 ed4105c0 0000c53e 000000d0 c0808600 eca77e5c 00000004 00000000
      [   62.779140] 7e40: bf000000 c0095680 c08075a0 ee001f00 ed4105c0 c00cadc0 ed52df80 bf000780
      [   62.787300] 7e60: ed4105c0 bf000780 00000001 bf0007c8 c0082f38 ed618340 000008c1 c0083e24
      [   62.795459] 7e80: 00000001 bf000780 00000001 eca77f58 00000001 bf000780 00000001 c00857f4
      [   62.803618] 7ea0: bf00078c 00007fff 00000000 c00835b4 eca77f58 00000000 c0082fac eca77f58
      [   62.811777] 7ec0: f05038c0 0003b008 bf000904 00000000 00000000 bf00078c 6e72656b 00006c65
      [   62.819936] 7ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [   62.828095] 7f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [   62.836255] 7f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000003 0003b008
      [   62.844414] 7f40: 0000017b c000f5c8 eca76000 00000000 0003b008 c0085df8 f04ef000 0001b8a9
      [   62.852573] 7f60: f0503258 f05030c2 f0509fe8 00000968 00000dc8 00000000 00000000 00000000
      [   62.860732] 7f80: 00000029 0000002a 00000011 00000000 0000000a 00000000 33f6eb00 0003b008
      [   62.868892] 7fa0: bef01cac c000f400 33f6eb00 0003b008 00000003 0003b008 00000000 00000003
      [   62.877051] 7fc0: 33f6eb00 0003b008 bef01cac 0000017b 00000000 0003b008 0000000b 0003b008
      [   62.885210] 7fe0: bef01ae0 bef01ad0 0001dc23 b6e8c162 800b0070 00000003 c0c0c0c0 c0c0c0c0
      [   62.893380] [<c01277c0>] (kernfs_find_ns) from [<c0824888>] (pm_qos_latency_tolerance_attr_group+0x0/0x10)
      [   62.903005] Code: e28dd00c e8bd80f0 e92d41f0 e2923000 (e1d0e4b4)
      [   62.909115] ---[ end trace 02fb4373ef095c7b ]---
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a27b3984
    • Krzysztof Opasiak's avatar
      usb: gadget: mass_storage: Free buffers if create lun fails · c387f28f
      Krzysztof Opasiak authored
      [ Upstream commit 903588a9 ]
      
      Creation of LUN 0 may fail (for example due to ENOMEM).
      As fsg_common_set_num_buffers() does some memory allocation
      we should free it before it becomes unavailable.
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c387f28f
    • Tiffany Lin's avatar
      [media] media: v4l2-compat-ioctl32: fix missing reserved field copy in put_v4l2_create32 · 5b1e4894
      Tiffany Lin authored
      [ Upstream commit baf43c6e ]
      
      In v4l2-compliance utility, test VIDIOC_CREATE_BUFS will check whether reserved
      filed of v4l2_create_buffers filled with zero
      Reserved field is filled with zero in v4l_create_bufs.
      This patch copy reserved field of v4l2_create_buffer from kernel space to user
      space
      Signed-off-by: default avatarTiffany Lin <tiffany.lin@mediatek.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: <stable@vger.kernel.org>      # for v3.19 and up
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5b1e4894
    • Andy Shevchenko's avatar
      mfd: intel_quark_i2c_gpio: load gpio driver first · 633b243b
      Andy Shevchenko authored
      [ Upstream commit c39dc960 ]
      
      On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
      is able to generate interrupt, but interrupt line is connected to GPIO. That's
      why we have to have GPIO driver in place when we will probe i2c host with
      device connected to it.
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      633b243b
    • Dave Gerlach's avatar
      cpuidle: Indicate when a device has been unregistered · 16de7980
      Dave Gerlach authored
      [ Upstream commit c998c078 ]
      
      Currently the 'registered' member of the cpuidle_device struct is set
      to 1 during cpuidle_register_device. In this same function there are
      checks to see if the device is already registered to prevent duplicate
      calls to register the device, but this value is never set to 0 even on
      unregister of the device. Because of this, any attempt to call
      cpuidle_register_device after a call to cpuidle_unregister_device will
      fail which shouldn't be the case.
      
      To prevent this, set registered to 0 when the device is unregistered.
      
      Fixes: c878a52d (cpuidle: Check if device is already registered)
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      16de7980
    • Jiri Slaby's avatar
      Bluetooth: vhci: purge unhandled skbs · b2df540f
      Jiri Slaby authored
      [ Upstream commit 13407376 ]
      
      The write handler allocates skbs and queues them into data->readq.
      Read side should read them, if there is any. If there is none, skbs
      should be dropped by hdev->flush. But this happens only if the device
      is HCI_UP, i.e. hdev->power_on work was triggered already. When it was
      not, skbs stay allocated in the queue when /dev/vhci is closed. So
      purge the queue in ->release.
      
      Program to reproduce:
      	#include <err.h>
      	#include <fcntl.h>
      	#include <stdio.h>
      	#include <unistd.h>
      
      	#include <sys/stat.h>
      	#include <sys/types.h>
      	#include <sys/uio.h>
      
      	int main()
      	{
      		char buf[] = { 0xff, 0 };
      		struct iovec iov = {
      			.iov_base = buf,
      			.iov_len = sizeof(buf),
      		};
      		int fd;
      
      		while (1) {
      			fd = open("/dev/vhci", O_RDWR);
      			if (fd < 0)
      				err(1, "open");
      
      			usleep(50);
      
      			if (writev(fd, &iov, 1) < 0)
      				err(1, "writev");
      
      			usleep(50);
      
      			close(fd);
      		}
      
      		return 0;
      	}
      
      Result:
      kmemleak: 4609 new suspected memory leaks
      unreferenced object 0xffff88059f4d5440 (size 232):
        comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s)
        hex dump (first 32 bytes):
          20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff   .#..... .#.....
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
      ...
          [<ffffffff81ece010>] __alloc_skb+0x0/0x5a0
          [<ffffffffa021886c>] vhci_create_device+0x5c/0x580 [hci_vhci]
          [<ffffffffa0219436>] vhci_write+0x306/0x4c8 [hci_vhci]
      
      Fixes: 23424c0d (Bluetooth: Add support creating virtual AMP controllers)
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable 3.13+ <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b2df540f
    • Jiri Slaby's avatar
      Bluetooth: vhci: fix open_timeout vs. hdev race · 497519c4
      Jiri Slaby authored
      [ Upstream commit 373a32c8 ]
      
      Both vhci_get_user and vhci_release race with open_timeout work. They
      both contain cancel_delayed_work_sync, but do not test whether the
      work actually created hdev or not. Since the work can be in progress
      and _sync will wait for finishing it, we can have data->hdev allocated
      when cancel_delayed_work_sync returns. But the call sites do 'if
      (data->hdev)' *before* cancel_delayed_work_sync.
      
      As a result:
      * vhci_get_user allocates a second hdev and puts it into
        data->hdev. The former is leaked.
      * vhci_release does not release data->hdev properly as it thinks there
        is none.
      
      Fix both cases by moving the actual test *after* the call to
      cancel_delayed_work_sync.
      
      This can be hit by this program:
      	#include <err.h>
      	#include <fcntl.h>
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <time.h>
      	#include <unistd.h>
      
      	#include <sys/stat.h>
      	#include <sys/types.h>
      
      	int main(int argc, char **argv)
      	{
      		int fd;
      
      		srand(time(NULL));
      
      		while (1) {
      			const int delta = (rand() % 200 - 100) * 100;
      
      			fd = open("/dev/vhci", O_RDWR);
      			if (fd < 0)
      				err(1, "open");
      
      			usleep(1000000 + delta);
      
      			close(fd);
      		}
      
      		return 0;
      	}
      
      And the result is:
      BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228
      Read of size 8 by task kworker/u13:1/32068
      =============================================================================
      BUG kmalloc-192 (Tainted: G            E     ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040
      ...
      	kmem_cache_alloc_trace+0x150/0x190
      	vhci_open+0x50/0x330 [hci_vhci]
      	misc_open+0x35b/0x4e0
      	chrdev_open+0x23b/0x510
      ...
      INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040
      ...
      	__slab_free+0x204/0x310
      	vhci_release+0xa4/0xd0 [hci_vhci]
      ...
      INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080
      INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600
      Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00  ...k............
      Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff  ...k.......k....
      Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff  .F.k.....F.k....
      Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00  ................
      Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff  @..k....@..k....
      Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de  P.n.............
      Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00  .........b......
      Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff  ........8..k....
      Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00  .. .............
      Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff  ...........=....
      Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00  . ..............
      Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb                          ........
      Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00                          ........
      CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G    B       E      4.4.6-0-default #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
      Workqueue: hci0 hci_cmd_work [bluetooth]
       00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180
       ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320
       ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80
      Call Trace:
      ...
       [<ffffffff81ec8ebe>] ? skb_queue_tail+0x13e/0x150
       [<ffffffffa06e027c>] ? vhci_send_frame+0xac/0x100 [hci_vhci]
       [<ffffffffa0c61268>] ? hci_send_frame+0x188/0x320 [bluetooth]
       [<ffffffffa0c61515>] ? hci_cmd_work+0x115/0x310 [bluetooth]
       [<ffffffff811a1375>] ? process_one_work+0x815/0x1340
       [<ffffffff811a1f85>] ? worker_thread+0xe5/0x11f0
       [<ffffffff811a1ea0>] ? process_one_work+0x1340/0x1340
       [<ffffffff811b3c68>] ? kthread+0x1c8/0x230
      ...
      Memory state around the buggy address:
       ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                        ^
       ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      
      Fixes: 23424c0d (Bluetooth: Add support creating virtual AMP controllers)
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: stable 3.13+ <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      497519c4
    • Itai Handler's avatar
      drm/gma500: Fix possible out of bounds read · dde14390
      Itai Handler authored
      [ Upstream commit 7ccca1d5 ]
      
      Fix possible out of bounds read, by adding missing comma.
      The code may read pass the end of the dsi_errors array
      when the most significant bit (bit #31) in the intr_stat register
      is set.
      This bug has been detected using CppCheck (static analysis tool).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarItai Handler <itai_handler@hotmail.com>
      Signed-off-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      dde14390
    • Larry Finger's avatar
      rtlwifi: btcoexist: Implement antenna selection · f448f477
      Larry Finger authored
      [ Upstream commit baa17022 ]
      
      The previous patch added an option to rtl8723be to manually select the
      antenna for those cases when only a single antenna is present, and the
      on-board EEPROM is incorrectly programmed. This patch implements the
      necessary changes in the Bluetooth coexistence driver.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org> [V4.0+]
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f448f477
    • Larry Finger's avatar
      rtlwifi: rtl8723be: Add antenna select module parameter · 7138f984
      Larry Finger authored
      [ Upstream commit c18d8f50 ]
      
      A number of new laptops have been delivered with only a single antenna.
      In principle, this is OK; however, a problem arises when the on-board
      EEPROM is programmed to use the other antenna connection. The option
      of opening the computer and moving the connector is not always possible
      as it will void the warranty in some cases. In addition, this solution
      breaks the Windows driver when the box dual boots Linux and Windows.
      
      A fix involving a new module parameter has been developed.  This commit
      adds the new parameter and implements the changes needed for the driver.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org> [V4.0+]
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7138f984
    • Sasha Levin's avatar
      rtlwifi: rtl8723be: Fix module parameter initialization · db4ec7cf
      Sasha Levin authored
      [ Upstream commit 7079604d ]
      
      This driver has a number of errors in the module initialization. These
      include the following:
      
      Parameter msi_support is stored in two places - one is removed.
      Paramters sw_crypto and disable_watchdog were never stored in the final
      locations, nor were they initialized properly.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      db4ec7cf
    • Darrick J. Wong's avatar
      libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct · e8663801
      Darrick J. Wong authored
      [ Upstream commit 96f859d5 ]
      
      Because struct xfs_agfl is 36 bytes long and has a 64-bit integer
      inside it, gcc will quietly round the structure size up to the nearest
      64 bits -- in this case, 40 bytes.  This results in the XFS_AGFL_SIZE
      macro returning incorrect results for v5 filesystems on 64-bit
      machines (118 items instead of 119).  As a result, a 32-bit xfs_repair
      will see garbage in AGFL item 119 and complain.
      
      Therefore, tell gcc not to pad the structure so that the AGFL size
      calculation is correct.
      
      cc: <stable@vger.kernel.org> # 3.10 - 4.4
      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 avatarSasha Levin <sasha.levin@oracle.com>
      e8663801
  2. 01 Jun, 2016 4 commits
    • Dave Chinner's avatar
      xfs: Don't wrap growfs AGFL indexes · 1fe949f6
      Dave Chinner authored
      [ Upstream commit ad747e3b ]
      
      Commit 96f859d5 ("libxfs: pack the agfl header structure so
      XFS_AGFL_SIZE is correct") allowed the freelist to use the empty
      slot at the end of the freelist on 64 bit systems that was not
      being used due to sizeof() rounding up the structure size.
      
      This has caused versions of xfs_repair prior to 4.5.0 (which also
      has the fix) to report this as a corruption once the filesystem has
      been grown. Older kernels can also have problems (seen from a whacky
      container/vm management environment) mounting filesystems grown on a
      system with a newer kernel than the vm/container it is deployed on.
      
      To avoid this problem, change the initial free list indexes not to
      wrap across the end of the AGFL, hence avoiding the initialisation
      of agf_fllast to the last index in the AGFL.
      
      cc: <stable@vger.kernel.org> # 4.4-4.5
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarCarlos Maiolino <cmaiolino@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1fe949f6
    • Eric Sandeen's avatar
      xfs: disallow rw remount on fs with unknown ro-compat features · 9c153a82
      Eric Sandeen authored
      [ Upstream commit d0a58e83 ]
      
      Today, a kernel which refuses to mount a filesystem read-write
      due to unknown ro-compat features can still transition to read-write
      via the remount path.  The old kernel is most likely none the wiser,
      because it's unaware of the new feature, and isn't using it.  However,
      writing to the filesystem may well corrupt metadata related to that
      new feature, and moving to a newer kernel which understand the feature
      will have problems.
      
      Right now the only ro-compat feature we have is the free inode btree,
      which showed up in v3.16.  It would be good to push this back to
      all the active stable kernels, I think, so that if anyone is using
      newer mkfs (which enables the finobt feature) with older kernel
      releases, they'll be protected.
      
      Cc: <stable@vger.kernel.org> # 3.10.x-
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Reviewed-by: default avatarBill O'Donnell <billodo@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      9c153a82
    • Joseph Salisbury's avatar
      ath5k: Change led pin configuration for compaq c700 laptop · 67b8cea5
      Joseph Salisbury authored
      [ Upstream commit 7b9bc799 ]
      
      BugLink: http://bugs.launchpad.net/bugs/972604
      
      Commit 09c9bae2 ("ath5k: add led pin
      configuration for compaq c700 laptop") added a pin configuration for the Compaq
      c700 laptop.  However, the polarity of the led pin is reversed.  It should be
      red for wifi off and blue for wifi on, but it is the opposite.  This bug was
      reported in the following bug report:
      http://pad.lv/972604
      
      Fixes: 09c9bae2 ("ath5k: add led pin configuration for compaq c700 laptop")
      Signed-off-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      67b8cea5
    • Javier Martinez Canillas's avatar
      regulator: Try to resolve regulators supplies on registration · db9c6316
      Javier Martinez Canillas authored
      [ Upstream commit 5e3ca2b3 ]
      
      Commit 6261b06d ("regulator: Defer lookup of supply to regulator_get")
      moved the regulator supplies lookup logic from the regulators registration
      to the regulators get time.
      
      Unfortunately, that changed the behavior of the regulator core since now a
      parent supply with a child regulator marked as always-on, won't be enabled
      unless a client driver attempts to get the child regulator during boot.
      
      This patch tries to resolve the parent supply for the already registered
      regulators each time that a new regulator is registered. So the regulators
      that have child regulators marked as always on will be enabled regardless
      if a driver gets the child regulator or not.
      
      That was the behavior before the mentioned commit, since parent supplies
      were looked up at regulator registration time instead of during child get.
      
      Since regulator_resolve_supply() checks for rdev->supply, most of the times
      it will be a no-op. Errors aren't checked to keep the possible out of order
      dependencies which was the motivation for the mentioned commit.
      
      Also, the supply being available will be enforced on regulator get anyways
      in case the resolve fails on regulators registration.
      
      Fixes: 6261b06d ("regulator: Defer lookup of supply to regulator_get")
      Suggested-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: <stable@vger.kernel.org> # 4.1+
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      db9c6316