1. 01 Jun, 2016 40 commits
    • H Hartley Sweeten's avatar
      staging: comedi: das1800: fix possible NULL dereference · 023bea74
      H Hartley Sweeten authored
      commit d375278d upstream.
      
      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")
      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>
      023bea74
    • Yoshihiro Shimoda's avatar
      usb: gadget: udc: core: Fix argument of dev_err() in usb_gadget_map_request() · 53c24ba2
      Yoshihiro Shimoda authored
      commit 5096c4d3 upstream.
      
      The argument of dev_err() in usb_gadget_map_request() should be dev
      instead of &gadget->dev.
      
      Fixes: 7ace8fc8 ("usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53c24ba2
    • Alan Stern's avatar
      USB: leave LPM alone if possible when binding/unbinding interface drivers · 15e67f90
      Alan Stern authored
      commit 6fb650d4 upstream.
      
      When a USB driver is bound to an interface (either through probing or
      by claiming it) or is unbound from an interface, the USB core always
      disables Link Power Management during the transition and then
      re-enables it afterward.  The reason is because the driver might want
      to prevent hub-initiated link power transitions, in which case the HCD
      would have to recalculate the various LPM parameters.  This
      recalculation takes place when LPM is re-enabled and the new
      parameters are sent to the device and its parent hub.
      
      However, if the driver does not want to prevent hub-initiated link
      power transitions then none of this work is necessary.  The parameters
      don't need to be recalculated, and LPM doesn't need to be disabled and
      re-enabled.
      
      It turns out that disabling and enabling LPM can be time-consuming,
      enough so that it interferes with user programs that want to claim and
      release interfaces rapidly via usbfs.  Since the usbfs kernel driver
      doesn't set the disable_hub_initiated_lpm flag, we can speed things up
      and get the user programs to work by leaving LPM alone whenever the
      flag isn't set.
      
      And while we're improving the way disable_hub_initiated_lpm gets used,
      let's also fix its kerneldoc.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarMatthew Giassa <matthew@giassa.net>
      CC: Mathias Nyman <mathias.nyman@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      15e67f90
    • Mathias Nyman's avatar
      usb: misc: usbtest: fix pattern tests for scatterlists. · e3a037a5
      Mathias Nyman authored
      commit cdc77c82 upstream.
      
      The current implemenentation restart the sent pattern for each entry in
      the sg list. The receiving end expects a continuous pattern, and test
      will fail unless scatterilst entries happen to be aligned with the
      pattern
      
      Fix this by calculating the pattern byte based on total sent size
      instead of just the current sg entry.
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Fixes: 8b524901 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing")
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3a037a5
    • Michal Nazarewicz's avatar
      usb: f_mass_storage: test whether thread is running before starting another · 51c31279
      Michal Nazarewicz authored
      commit f78bbcae upstream.
      
      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>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51c31279
    • Lars-Peter Clausen's avatar
      usb: gadget: f_fs: Fix EFAULT generation for async read operations · ed97f0d9
      Lars-Peter Clausen authored
      commit 332a5b44 upstream.
      
      In the current implementation functionfs generates a EFAULT for async read
      operations if the read buffer size is larger than the URB data size. Since
      a application does not necessarily know how much data the host side is
      going to send it typically supplies a buffer larger than the actual data,
      which will then result in a EFAULT error.
      
      This behaviour was introduced while refactoring the code to use iov_iter
      interface in commit c993c39b ("gadget/function/f_fs.c: use put iov_iter
      into io_data"). The original code took the minimum over the URB size and
      the user buffer size and then attempted to copy that many bytes using
      copy_to_user(). If copy_to_user() could not copy all data a EFAULT error
      was generated. Restore the original behaviour by only generating a EFAULT
      error when the number of bytes copied is not the size of the URB and the
      target buffer has not been fully filled.
      
      Commit 342f39a6 ("usb: gadget: f_fs: fix check in read operation")
      already fixed the same problem for the synchronous read path.
      
      Fixes: c993c39b ("gadget/function/f_fs.c: use put iov_iter into io_data")
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed97f0d9
    • Lei Liu's avatar
      USB: serial: option: add even more ZTE device ids · 92f54c19
      Lei Liu authored
      commit 74d2a91a upstream.
      
      Add even more ZTE device ids.
      Signed-off-by: default avatarlei liu <liu.lei78@zte.com.cn>
      [johan: rebase and replace commit message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92f54c19
    • lei liu's avatar
      USB: serial: option: add more ZTE device ids · 9ec187e5
      lei liu authored
      commit f0d09463 upstream.
      
      More ZTE device ids.
      Signed-off-by: default avatarlei liu <liu.lei78@zte.com.cn>
      [properly sort them - gregkh]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ec187e5
    • Schemmel Hans-Christoph's avatar
      USB: serial: option: add support for Cinterion PH8 and AHxx · 50e76529
      Schemmel Hans-Christoph authored
      commit 444f94e9 upstream.
      
      Added support for Gemalto's Cinterion PH8 and AHxx products
      with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface.
      
      In addition some minor renaming and formatting.
      Signed-off-by: default avatarHans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
      [johan: sort current entries and trim trailing whitespace ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50e76529
    • Johan Hovold's avatar
      USB: serial: io_edgeport: fix memory leaks in probe error path · 7cb5461c
      Johan Hovold authored
      commit c8d62957 upstream.
      
      URBs and buffers allocated in attach for Epic devices would never be
      deallocated in case of a later probe error (e.g. failure to allocate
      minor numbers) as disconnect is then never called.
      
      Fix by moving deallocation to release and making sure that the
      URBs are first unlinked.
      
      Fixes: f9c99bb8 ("USB: usb-serial: replace shutdown with disconnect,
      release")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cb5461c
    • Johan Hovold's avatar
      USB: serial: io_edgeport: fix memory leaks in attach error path · d6f69570
      Johan Hovold authored
      commit c5c0c555 upstream.
      
      Private data, URBs and buffers allocated for Epic devices during
      attach were never released on errors (e.g. missing endpoints).
      
      Fixes: 6e8cf775 ("USB: add EPIC support to the io_edgeport driver")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6f69570
    • Johan Hovold's avatar
      USB: serial: quatech2: fix use-after-free in probe error path · 68f03961
      Johan Hovold authored
      commit 028c49f5 upstream.
      
      The interface read URB is submitted in attach, but was only unlinked by
      the driver at disconnect.
      
      In case of a late probe error (e.g. due to failed minor allocation),
      disconnect is never called and we would end up with active URBs for an
      unbound interface. This in turn could lead to deallocated memory being
      dereferenced in the completion callback.
      
      Fixes: f7a33e60 ("USB: serial: add quatech2 usb to serial driver")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68f03961
    • Johan Hovold's avatar
      USB: serial: keyspan: fix use-after-free in probe error path · 00efa6c2
      Johan Hovold authored
      commit 35be1a71 upstream.
      
      The interface instat and indat URBs were submitted in attach, but never
      unlinked in release before deallocating the corresponding transfer
      buffers.
      
      In the case of a late probe error (e.g. due to failed minor allocation),
      disconnect would not have been called before release, causing the
      buffers to be freed while the URBs are still in use. We'd also end up
      with active URBs for an unbound interface.
      
      Fixes: f9c99bb8 ("USB: usb-serial: replace shutdown with disconnect,
      release")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00efa6c2
    • Johan Hovold's avatar
      USB: serial: mxuport: fix use-after-free in probe error path · c0b572be
      Johan Hovold authored
      commit 9e452849 upstream.
      
      The interface read and event URBs are submitted in attach, but were
      never explicitly unlinked by the driver. Instead the URBs would have
      been killed by usb-serial core on disconnect.
      
      In case of a late probe error (e.g. due to failed minor allocation),
      disconnect is never called and we could end up with active URBs for an
      unbound interface. This in turn could lead to deallocated memory being
      dereferenced in the completion callbacks.
      
      Fixes: ee467a1f ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
      driver")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0b572be
    • Alexander Usyskin's avatar
      mei: bus: call mei_cl_read_start under device lock · 40f9ca60
      Alexander Usyskin authored
      commit bc46b45a upstream.
      
      Ensure that mei_cl_read_start is called under the device lock
      also in the bus layer. The function updates global ctrl_wr_list
      which should be locked.
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40f9ca60
    • Alexander Usyskin's avatar
      mei: amthif: discard not read messages · 2e6440e9
      Alexander Usyskin authored
      commit 9d04ee11 upstream.
      
      When a message is received and amthif client is not in reading state
      the message is ignored and left dangling in the queue. This may happen
      after one of the amthif host connections is closed w/o completing the
      reading. Another client will pick up a wrong message on next read
      attempt which will lead to link reset.
      To prevent this the driver has to properly discard the message when
      amthif client is not in reading state.
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e6440e9
    • Alexander Usyskin's avatar
      mei: fix NULL dereferencing during FW initiated disconnection · 2826506a
      Alexander Usyskin authored
      commit 6a8d648c upstream.
      
      In the case when disconnection is initiated from the FW
      the driver is flushing items from the write control list while
      iterating over it:
      
      mei_irq_write_handler()
          list_for_each_entry_safe(ctrl_wr_list)         <-- outer loop
               mei_cl_irq_disconnect_rsp()
                   mei_cl_set_disconnected()
                       mei_io_list_flush(ctrl_wr_list)   <-- destorying list
      
      We move the list flushing to the completion routine.
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2826506a
    • Takashi Iwai's avatar
      Bluetooth: vhci: Fix race at creating hci device · 2ceff6c4
      Takashi Iwai authored
      commit c7c999cb upstream.
      
      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.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ceff6c4
    • Jiri Slaby's avatar
      Bluetooth: vhci: purge unhandled skbs · 3295bfd3
      Jiri Slaby authored
      commit 13407376 upstream.
      
      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>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3295bfd3
    • Jiri Slaby's avatar
      Bluetooth: vhci: fix open_timeout vs. hdev race · 1af4f24c
      Jiri Slaby authored
      commit 373a32c8 upstream.
      
      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>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1af4f24c
    • Adrian Hunter's avatar
      mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers · 7973b064
      Adrian Hunter authored
      commit 82296936 upstream.
      
      The CMD19/CMD14 bus width test has been found to be unreliable in
      some cases.  It is not essential, so simply remove it.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7973b064
    • Matt Gumbel's avatar
      mmc: longer timeout for long read time quirk · 32971328
      Matt Gumbel authored
      commit 32ecd320 upstream.
      
      008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
      MMC_SEND_EXT_CSD in 450-600ms.
      
      This patch will...
      
      () Increase the long read time quirk timeout from 300ms to 600ms. Original
         author of that quirk says 300ms was only a guess and that the number
         may need to be raised in the future.
      
      () Add this specific MMC to the quirk
      Signed-off-by: default avatarMatt Gumbel <matthew.k.gumbel@intel.com>
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32971328
    • Gabriele Mazzotta's avatar
      dell-rbtn: Ignore ACPI notifications if device is suspended · 96cd084c
      Gabriele Mazzotta authored
      commit ff865123 upstream.
      
      Some BIOSes unconditionally send an ACPI notification to RBTN when the
      system is resuming from suspend. This makes dell-rbtn send an input
      event to userspace as if a function key was pressed. Prevent this by
      ignoring all the notifications received while the device is suspended.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031Signed-off-by: default avatarGabriele Mazzotta <gabriele.mzt@gmail.com>
      Tested-by: default avatarAlex Hung <alex.hung@canonical.com>
      Reviewed-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96cd084c
    • Lv Zheng's avatar
      ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings · 419b1d21
      Lv Zheng authored
      commit 30c9bb0d upstream.
      
      The order of the _OSI related functionalities is as follows:
      
        acpi_blacklisted()
          acpi_dmi_osi_linux()
            acpi_osi_setup()
          acpi_osi_setup()
            acpi_update_interfaces() if "!*"
            <<<<<<<<<<<<<<<<<<<<<<<<
        parse_args()
          __setup("acpi_osi=")
            acpi_osi_setup_linux()
              acpi_update_interfaces() if "!*"
              <<<<<<<<<<<<<<<<<<<<<<<<
        acpi_early_init()
          acpi_initialize_subsystem()
            acpi_ut_initialize_interfaces()
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        acpi_bus_init()
          acpi_os_initialize1()
            acpi_install_interface_handler(acpi_osi_handler)
            acpi_osi_setup_late()
              acpi_update_interfaces() for "!"
              >>>>>>>>>>>>>>>>>>>>>>>>
        acpi_osi_handler()
      
      Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command
      line setting can override the DMI detection. That's why acpi_blacklisted()
      is put before __setup("acpi_osi=").
      
      Then we can notice the following wrong invocation order. There are
      acpi_update_interfaces() (marked by <<<<) calls invoked before
      acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible
      to use acpi_osi=!* correctly from OSI DMI table or from the command line.
      The use of acpi_osi=!* is meant to disable both ACPICA
      (acpi_gbl_supported_interfaces) and Linux specific strings
      (osi_setup_entries) while the ACPICA part should have stopped working
      because of the order issue.
      
      This patch fixes this issue by moving acpi_update_interfaces() to where
      it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be
      invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux
      specific strings are still handled in the original place in order to make
      the following command line working: acpi_osi=!* acpi_osi="Module Device".
      
      Note that since acpi_osi=!* is meant to further disable linux specific
      string comparing to the acpi_osi=!, there is no such use case in our bug
      fixing work and hence there is no one using acpi_osi=!* either from the
      command line or from the DMI quirks, this issue is just a theoretical
      issue.
      
      Fixes: 741d8128 (ACPI: Add facility to remove all _OSI strings)
      Tested-by: default avatarLukas Wunner <lukas@wunner.de>
      Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      419b1d21
    • Adrian Hunter's avatar
      mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers · bb2b58c7
      Adrian Hunter authored
      commit 265984b3 upstream.
      
      The CMD19/CMD14 bus width test has been found to be unreliable in
      some cases.  It is not essential, so simply remove it.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb2b58c7
    • Adrian Hunter's avatar
      mmc: mmc: Fix partition switch timeout for some eMMCs · 98b0125d
      Adrian Hunter authored
      commit 1c447116 upstream.
      
      Some eMMCs set the partition switch timeout too low.
      
      Now typically eMMCs are considered a critical component (e.g. because
      they store the root file system) and consequently are expected to be
      reliable.  Thus we can neglect the use case where eMMCs can't switch
      reliably and we might want a lower timeout to facilitate speedy
      recovery.
      
      Although we could employ a quirk for the cards that are affected (if
      we could identify them all), as described above, there is little
      benefit to having a low timeout, so instead simply set a minimum
      timeout.
      
      The minimum is set to 300ms somewhat arbitrarily - the examples that
      have been seen had a timeout of 10ms but were sometimes taking 60-70ms.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98b0125d
    • Oliver Hartkopp's avatar
      can: fix handling of unmodifiable configuration options · 24bf50bc
      Oliver Hartkopp authored
      commit bb208f14 upstream.
      
      As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
      (6cfda7fb) it is possible to define fixed configuration options by
      setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
      This leads to the incovenience that the fixed configuration bits can not be
      passed by netlink even when they have the correct values (e.g. non-ISO, FD).
      
      This patch fixes that issue and not only allows fixed set bit values to be set
      again but now requires(!) to provide these fixed values at configuration time.
      A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
      data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
      enforced by a new can_validate() function. This fix additionally removed the
      inconsistency that was prohibiting the support of 'CANFD-only' controller
      drivers, like the RCar CAN FD.
      
      For this reason a new helper can_set_static_ctrlmode() has been introduced to
      provide a proper interface to handle static enabled CAN controller options.
      Reported-by: default avatarRamesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
      Signed-off-by: default avatarOliver Hartkopp <socketcan@hartkopp.net>
      Reviewed-by: default avatarRamesh Shanmugasundaram  <ramesh.shanmugasundaram@bp.renesas.com>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24bf50bc
    • Marc Zyngier's avatar
      irqchip/gic-v3: Configure all interrupts as non-secure Group-1 · 9b68f12b
      Marc Zyngier authored
      commit 7c9b9730 upstream.
      
      The GICv3 driver wrongly assumes that it runs on the non-secure
      side of a secure-enabled system, while it could be on a system
      with a single security state, or a GICv3 with GICD_CTLR.DS set.
      
      Either way, it is important to configure this properly, or
      interrupts will simply not be delivered on this HW.
      Reported-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Tested-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b68f12b
    • Will Deacon's avatar
      irqchip/gic: Ensure ordering between read of INTACK and shared data · 3607d54e
      Will Deacon authored
      commit f86c4fbd upstream.
      
      When an IPI is generated by a CPU, the pattern looks roughly like:
      
        <write shared data>
        smp_wmb();
        <write to GIC to signal SGI>
      
      On the receiving CPU we rely on the fact that, once we've taken the
      interrupt, then the freshly written shared data must be visible to us.
      Put another way, the CPU isn't going to speculate taking an interrupt.
      
      Unfortunately, this assumption turns out to be broken.
      
      Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
      to read some shared_data. Before CPUx has done anything, a random
      peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
      CPUy then takes the IRQ and starts executing the entry code, heading
      towards gic_handle_irq. Furthermore, let's assume that a bunch of the
      previous interrupts handled by CPUy were SGIs, so the branch predictor
      kicks in and speculates that irqnr will be <16 and we're likely to
      head into handle_IPI. The prefetcher then grabs a speculative copy of
      shared_data which contains a stale value.
      
      Meanwhile, CPUx gets round to updating shared_data and asking the GIC
      to send an SGI to CPUy. Internally, the GIC decides that the SGI is
      more important than the peripheral interrupt (which hasn't yet been
      ACKed) but doesn't need to do anything to CPUy, because the IRQ line
      is already raised.
      
      CPUy then reads the ACK register on the GIC, sees the SGI value which
      confirms the branch prediction and we end up with a stale shared_data
      value.
      
      This patch fixes the problem by adding an smp_rmb() to the IPI entry
      code in gic_handle_irq. As it turns out, the combination of a control
      dependency and an ISB instruction from the EOI in the GICv3 driver is
      enough to provide the ordering we need, so we add a comment there
      justifying the absence of an explicit smp_rmb().
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3607d54e
    • Manfred Schlaegl's avatar
      Input: pwm-beeper - fix - scheduling while atomic · 02c23447
      Manfred Schlaegl authored
      commit f49cf3b8 upstream.
      
      Pwm config may sleep so defer it using a worker.
      
      On a Freescale i.MX53 based board we ran into "BUG: scheduling while
      atomic" because input_inject_event locks interrupts, but
      imx_pwm_config_v2 sleeps.
      
      Tested on Freescale i.MX53 SoC with 4.6.0.
      Signed-off-by: default avatarManfred Schlaegl <manfred.schlaegl@gmx.at>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02c23447
    • Roger Quadros's avatar
      mfd: omap-usb-tll: Fix scheduling while atomic BUG · c5215990
      Roger Quadros authored
      commit b49b927f upstream.
      
      We shouldn't be calling clk_prepare_enable()/clk_prepare_disable()
      in an atomic context.
      
      Fixes the following issue:
      
      [    5.830970] ehci-omap: OMAP-EHCI Host Controller driver
      [    5.830974] driver_register 'ehci-omap'
      [    5.895849] driver_register 'wl1271_sdio'
      [    5.896870] BUG: scheduling while atomic: udevd/994/0x00000002
      [    5.896876] 4 locks held by udevd/994:
      [    5.896904]  #0:  (&dev->mutex){......}, at: [<c049597c>] __driver_attach+0x60/0xac
      [    5.896923]  #1:  (&dev->mutex){......}, at: [<c049598c>] __driver_attach+0x70/0xac
      [    5.896946]  #2:  (tll_lock){+.+...}, at: [<c04c2630>] omap_tll_enable+0x2c/0xd0
      [    5.896966]  #3:  (prepare_lock){+.+...}, at: [<c05ce9c8>] clk_prepare_lock+0x48/0xe0
      [    5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine
      [    5.897048] Preemption disabled at:[<  (null)>]   (null)
      [    5.897051]
      [    5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233
      [    5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree)
      [    5.897076] [<c010e714>] (unwind_backtrace) from [<c010af34>] (show_stack+0x10/0x14)
      [    5.897087] [<c010af34>] (show_stack) from [<c040aa7c>] (dump_stack+0x88/0xc0)
      [    5.897099] [<c040aa7c>] (dump_stack) from [<c020c558>] (__schedule_bug+0xac/0xd0)
      [    5.897111] [<c020c558>] (__schedule_bug) from [<c06f3d44>] (__schedule+0x88/0x7e4)
      [    5.897120] [<c06f3d44>] (__schedule) from [<c06f46d8>] (schedule+0x9c/0xc0)
      [    5.897129] [<c06f46d8>] (schedule) from [<c06f4904>] (schedule_preempt_disabled+0x14/0x20)
      [    5.897140] [<c06f4904>] (schedule_preempt_disabled) from [<c06f64e4>] (mutex_lock_nested+0x258/0x43c)
      [    5.897150] [<c06f64e4>] (mutex_lock_nested) from [<c05ce9c8>] (clk_prepare_lock+0x48/0xe0)
      [    5.897160] [<c05ce9c8>] (clk_prepare_lock) from [<c05d0e7c>] (clk_prepare+0x10/0x28)
      [    5.897169] [<c05d0e7c>] (clk_prepare) from [<c04c2668>] (omap_tll_enable+0x64/0xd0)
      [    5.897180] [<c04c2668>] (omap_tll_enable) from [<c04c1728>] (usbhs_runtime_resume+0x18/0x17c)
      [    5.897192] [<c04c1728>] (usbhs_runtime_resume) from [<c049d404>] (pm_generic_runtime_resume+0x2c/0x40)
      [    5.897202] [<c049d404>] (pm_generic_runtime_resume) from [<c049f180>] (__rpm_callback+0x38/0x68)
      [    5.897210] [<c049f180>] (__rpm_callback) from [<c049f220>] (rpm_callback+0x70/0x88)
      [    5.897218] [<c049f220>] (rpm_callback) from [<c04a0a00>] (rpm_resume+0x4ec/0x7ec)
      [    5.897227] [<c04a0a00>] (rpm_resume) from [<c04a0f48>] (__pm_runtime_resume+0x4c/0x64)
      [    5.897236] [<c04a0f48>] (__pm_runtime_resume) from [<c04958dc>] (driver_probe_device+0x30/0x70)
      [    5.897246] [<c04958dc>] (driver_probe_device) from [<c04959a4>] (__driver_attach+0x88/0xac)
      [    5.897256] [<c04959a4>] (__driver_attach) from [<c04940f8>] (bus_for_each_dev+0x50/0x84)
      [    5.897267] [<c04940f8>] (bus_for_each_dev) from [<c0494e40>] (bus_add_driver+0xcc/0x1e4)
      [    5.897276] [<c0494e40>] (bus_add_driver) from [<c0496914>] (driver_register+0xac/0xf4)
      [    5.897286] [<c0496914>] (driver_register) from [<c01018e0>] (do_one_initcall+0x100/0x1b8)
      [    5.897296] [<c01018e0>] (do_one_initcall) from [<c01c7a54>] (do_init_module+0x58/0x1c0)
      [    5.897304] [<c01c7a54>] (do_init_module) from [<c01c8a3c>] (SyS_finit_module+0x88/0x90)
      [    5.897313] [<c01c8a3c>] (SyS_finit_module) from [<c0107120>] (ret_fast_syscall+0x0/0x1c)
      [    5.912697] ------------[ cut here ]------------
      [    5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58
      [    5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count())
      Reported-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Tested-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5215990
    • Vik Heyndrickx's avatar
      sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems · 1df73f18
      Vik Heyndrickx authored
      commit 20878232 upstream.
      
      Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
      have no load at all.
      
      Uptime and /proc/loadavg on all systems with kernels released during the
      last five years up until kernel version 4.6-rc5, show a 5- and 15-minute
      minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
      idle systems, but the way the kernel calculates this value prevents it
      from getting lower than the mentioned values.
      
      Likewise but not as obviously noticeable, a fully loaded system with no
      processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95
      (multiplied by number of cores).
      
      Once the (old) load becomes 93 or higher, it mathematically can never
      get lower than 93, even when the active (load) remains 0 forever.
      This results in the strange 0.00, 0.01, 0.05 uptime values on idle
      systems.  Note: 93/2048 = 0.0454..., which rounds up to 0.05.
      
      It is not correct to add a 0.5 rounding (=1024/2048) here, since the
      result from this function is fed back into the next iteration again,
      so the result of that +0.5 rounding value then gets multiplied by
      (2048-2037), and then rounded again, so there is a virtual "ghost"
      load created, next to the old and active load terms.
      
      By changing the way the internally kept value is rounded, that internal
      value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon
      increasing load, the internally kept load value is rounded up, when the
      load is decreasing, the load value is rounded down.
      
      The modified code was tested on nohz=off and nohz kernels. It was tested
      on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was
      tested on single, dual, and octal cores system. It was tested on virtual
      hosts and bare hardware. No unwanted effects have been observed, and the
      problems that the patch intended to fix were indeed gone.
      Tested-by: default avatarDamien Wyart <damien.wyart@free.fr>
      Signed-off-by: default avatarVik Heyndrickx <vik.heyndrickx@veribox.net>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Doug Smythies <dsmythies@telus.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 0f004f5a ("sched: Cure more NO_HZ load average woes")
      Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f09f@veribox.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1df73f18
    • Andy Gross's avatar
      clk: qcom: msm8916: Fix crypto clock flags · aef53169
      Andy Gross authored
      commit 2a0974aa upstream.
      
      This patch adds the CLK_SET_RATE_PARENT flag for the crypto core and
      ahb blocks.  Without this flag, clk_set_rate can fail for certain
      frequency requests.
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      Fixes: 3966fab8 ("clk: qcom: Add MSM8916 Global Clock Controller support")
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aef53169
    • Corentin LABBE's avatar
      crypto: sun4i-ss - Replace spinlock_bh by spin_lock_irq{save|restore} · a80e1fbf
      Corentin LABBE authored
      commit bdb6cf9f upstream.
      
      The current sun4i-ss driver could generate data corruption when ciphering/deciphering.
      It occurs randomly on end of handled data.
      No root cause have been found and the only way to remove it is to replace
      all spin_lock_bh by their irq counterparts.
      
      Fixes: 6298e948 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
      Signed-off-by: default avatarLABBE Corentin <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a80e1fbf
    • Horia Geant?'s avatar
      crypto: talitos - fix ahash algorithms registration · efc1e73c
      Horia Geant? authored
      commit 3639ca84 upstream.
      
      Provide hardware state import/export functionality, as mandated by
      commit 8996eafd ("crypto: ahash - ensure statesize is non-zero")
      Reported-by: default avatarJonas Eymann <J.Eymann@gmx.net>
      Signed-off-by: default avatarHoria Geant? <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      efc1e73c
    • Catalin Vasile's avatar
      crypto: caam - fix caam_jr_alloc() ret code · fd97b4fb
      Catalin Vasile authored
      commit e930c765 upstream.
      
      caam_jr_alloc() used to return NULL if a JR device could not be
      allocated for a session. In turn, every user of this function used
      IS_ERR() function to verify if anything went wrong, which does NOT look
      for NULL values. This made the kernel crash if the sanity check failed,
      because the driver continued to think it had allocated a valid JR dev
      instance to the session and at some point it tries to do a caam_jr_free()
      on a NULL JR dev pointer.
      This patch is a fix for this issue.
      Signed-off-by: default avatarCatalin Vasile <cata.vasile@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd97b4fb
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Prevent overflow of size in ring_buffer_resize() · f1990231
      Steven Rostedt (Red Hat) authored
      commit 59643d15 upstream.
      
      If the size passed to ring_buffer_resize() is greater than MAX_LONG - BUF_PAGE_SIZE
      then the DIV_ROUND_UP() will return zero.
      
      Here's the details:
      
        # echo 18014398509481980 > /sys/kernel/debug/tracing/buffer_size_kb
      
      tracing_entries_write() processes this and converts kb to bytes.
      
       18014398509481980 << 10 = 18446744073709547520
      
      and this is passed to ring_buffer_resize() as unsigned long size.
      
       size = DIV_ROUND_UP(size, BUF_PAGE_SIZE);
      
      Where DIV_ROUND_UP(a, b) is (a + b - 1)/b
      
      BUF_PAGE_SIZE is 4080 and here
      
       18446744073709547520 + 4080 - 1 = 18446744073709551599
      
      where 18446744073709551599 is still smaller than 2^64
      
       2^64 - 18446744073709551599 = 17
      
      But now 18446744073709551599 / 4080 = 4521260802379792
      
      and size = size * 4080 = 18446744073709551360
      
      This is checked to make sure its still greater than 2 * 4080,
      which it is.
      
      Then we convert to the number of buffer pages needed.
      
       nr_page = DIV_ROUND_UP(size, BUF_PAGE_SIZE)
      
      but this time size is 18446744073709551360 and
      
       2^64 - (18446744073709551360 + 4080 - 1) = -3823
      
      Thus it overflows and the resulting number is less than 4080, which makes
      
        3823 / 4080 = 0
      
      an nr_pages is set to this. As we already checked against the minimum that
      nr_pages may be, this causes the logic to fail as well, and we crash the
      kernel.
      
      There's no reason to have the two DIV_ROUND_UP() (that's just result of
      historical code changes), clean up the code and fix this bug.
      
      Fixes: 83f40318 ("ring-buffer: Make removal of ring buffer pages atomic")
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1990231
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Use long for nr_pages to avoid overflow failures · dfb71aef
      Steven Rostedt (Red Hat) authored
      commit 9b94a8fb upstream.
      
      The size variable to change the ring buffer in ftrace is a long. The
      nr_pages used to update the ring buffer based on the size is int. On 64 bit
      machines this can cause an overflow problem.
      
      For example, the following will cause the ring buffer to crash:
      
       # cd /sys/kernel/debug/tracing
       # echo 10 > buffer_size_kb
       # echo 8556384240 > buffer_size_kb
      
      Then you get the warning of:
      
       WARNING: CPU: 1 PID: 318 at kernel/trace/ring_buffer.c:1527 rb_update_pages+0x22f/0x260
      
      Which is:
      
        RB_WARN_ON(cpu_buffer, nr_removed);
      
      Note each ring buffer page holds 4080 bytes.
      
      This is because:
      
       1) 10 causes the ring buffer to have 3 pages.
          (10kb requires 3 * 4080 pages to hold)
      
       2) (2^31 / 2^10  + 1) * 4080 = 8556384240
          The value written into buffer_size_kb is shifted by 10 and then passed
          to ring_buffer_resize(). 8556384240 * 2^10 = 8761737461760
      
       3) The size passed to ring_buffer_resize() is then divided by BUF_PAGE_SIZE
          which is 4080. 8761737461760 / 4080 = 2147484672
      
       4) nr_pages is subtracted from the current nr_pages (3) and we get:
          2147484669. This value is saved in a signed integer nr_pages_to_update
      
       5) 2147484669 is greater than 2^31 but smaller than 2^32, a signed int
          turns into the value of -2147482627
      
       6) As the value is a negative number, in update_pages_handler() it is
          negated and passed to rb_remove_pages() and 2147482627 pages will
          be removed, which is much larger than 3 and it causes the warning
          because not all the pages asked to be removed were removed.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=118001
      
      Fixes: 7a8e76a3 ("tracing: unified trace buffer")
      Reported-by: default avatarHao Qin <QEver.cn@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfb71aef
    • John Stultz's avatar
      asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions · 0e4d7a01
      John Stultz authored
      commit cd9e2e5d upstream.
      
      In testing with HiKey, we found that since
      commit 3f30b158 ("asix: On RX avoid creating bad Ethernet
      frames"),
      we're seeing lots of noise during network transfers:
      
      [  239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x54ebb5ec, offset 4
      [  239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xcdffe7a2, offset 4
      [  239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x1d36f59d, offset 4
      [  239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xaef3c1e9, offset 4
      [  239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988
      [  239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x2881912, offset 4
      [  239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x5638f7e2, offset 4
      
      And network throughput ends up being pretty bursty and slow with
      a overall throughput of at best ~30kB/s (where as previously we
      got 1.1MB/s with the slower USB1.1 "full speed" host).
      
      We found the issue also was reproducible on a x86_64 system,
      using a "high-speed" USB2.0 port but the throughput did not
      measurably drop (possibly due to the scp transfer being cpu
      bound on my slow test hardware).
      
      After lots of debugging, I found the check added in the
      problematic commit seems to be calculating the offset
      incorrectly.
      
      In the normal case, in the main loop of the function, we do:
      (where offset is zero, or set to "offset += (copy_length + 1) &
      0xfffe" in the previous loop)
          rx->header = get_unaligned_le32(skb->data +
                                          offset);
          offset += sizeof(u32);
      
      But the problematic patch calculates:
          offset = ((rx->remaining + 1) & 0xfffe) + sizeof(u32);
          rx->header = get_unaligned_le32(skb->data + offset);
      
      Adding some debug logic to check those offset calculation used
      to find rx->header, the one in problematic code is always too
      large by sizeof(u32).
      
      Thus, this patch removes the incorrect " + sizeof(u32)" addition
      in the problematic calculation, and resolves the issue.
      
      Cc: Dean Jenkins <Dean_Jenkins@mentor.com>
      Cc: "David B. Robins" <linux@davidrobins.net>
      Cc: Mark Craske <Mark_Craske@mentor.com>
      Cc: Emil Goode <emilgoode@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: YongQin Liu <yongqin.liu@linaro.org>
      Cc: Guodong Xu <guodong.xu@linaro.org>
      Cc: Ivan Vecera <ivecera@redhat.com>
      Cc: linux-usb@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Reported-by: default avatarYongqin Liu <yongqin.liu@linaro.org>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e4d7a01
    • Stefan Metzmacher's avatar
      fs/cifs: correctly to anonymous authentication for the NTLM(v2) authentication · 6b83512b
      Stefan Metzmacher authored
      commit 1a967d6c upstream.
      
      Only server which map unknown users to guest will allow
      access using a non-null NTLMv2_Response.
      
      For Samba it's the "map to guest = bad user" option.
      
      BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913Signed-off-by: default avatarStefan Metzmacher <metze@samba.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b83512b