1. 22 Mar, 2017 10 commits
  2. 18 Mar, 2017 30 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.10.4 · 8ea22fb3
      Greg Kroah-Hartman authored
      8ea22fb3
    • Kamal Heib's avatar
      IB/mlx5: Verify that Q counters are supported · 42b16fff
      Kamal Heib authored
      commit 45bded2c upstream.
      
      Make sure that the Q counters are supported by the FW before trying
      to allocate/deallocte them, this will avoid driver load failure when
      they aren't supported by the FW.
      
      Fixes: 0837e86a ('IB/mlx5: Add per port counters')
      Signed-off-by: default avatarKamal Heib <kamalh@mellanox.com>
      Reviewed-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      42b16fff
    • Theodore Ts'o's avatar
      ext4: don't BUG when truncating encrypted inodes on the orphan list · dc37bb8d
      Theodore Ts'o authored
      commit 0d06863f upstream.
      
      Fix a BUG when the kernel tries to mount a file system constructed as
      follows:
      
      echo foo > foo.txt
      mke2fs -Fq -t ext4 -O encrypt foo.img 100
      debugfs -w foo.img << EOF
      write foo.txt a
      set_inode_field a i_flags 0x80800
      set_super_value s_last_orphan 12
      quit
      EOF
      
      root@kvm-xfstests:~# mount -o loop foo.img /mnt
      [  160.238770] ------------[ cut here ]------------
      [  160.240106] kernel BUG at /usr/projects/linux/ext4/fs/ext4/inode.c:3874!
      [  160.240106] invalid opcode: 0000 [#1] SMP
      [  160.240106] Modules linked in:
      [  160.240106] CPU: 0 PID: 2547 Comm: mount Tainted: G        W       4.10.0-rc3-00034-gcdd33b941b67 #227
      [  160.240106] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1 04/01/2014
      [  160.240106] task: f4518000 task.stack: f47b6000
      [  160.240106] EIP: ext4_block_zero_page_range+0x1a7/0x2b4
      [  160.240106] EFLAGS: 00010246 CPU: 0
      [  160.240106] EAX: 00000001 EBX: f7be4b50 ECX: f47b7dc0 EDX: 00000007
      [  160.240106] ESI: f43b05a8 EDI: f43babec EBP: f47b7dd0 ESP: f47b7dac
      [  160.240106]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  160.240106] CR0: 80050033 CR2: bfd85b08 CR3: 34a00680 CR4: 000006f0
      [  160.240106] Call Trace:
      [  160.240106]  ext4_truncate+0x1e9/0x3e5
      [  160.240106]  ext4_fill_super+0x286f/0x2b1e
      [  160.240106]  ? set_blocksize+0x2e/0x7e
      [  160.240106]  mount_bdev+0x114/0x15f
      [  160.240106]  ext4_mount+0x15/0x17
      [  160.240106]  ? ext4_calculate_overhead+0x39d/0x39d
      [  160.240106]  mount_fs+0x58/0x115
      [  160.240106]  vfs_kern_mount+0x4b/0xae
      [  160.240106]  do_mount+0x671/0x8c3
      [  160.240106]  ? _copy_from_user+0x70/0x83
      [  160.240106]  ? strndup_user+0x31/0x46
      [  160.240106]  SyS_mount+0x57/0x7b
      [  160.240106]  do_int80_syscall_32+0x4f/0x61
      [  160.240106]  entry_INT80_32+0x2f/0x2f
      [  160.240106] EIP: 0xb76b919e
      [  160.240106] EFLAGS: 00000246 CPU: 0
      [  160.240106] EAX: ffffffda EBX: 08053838 ECX: 08052188 EDX: 080537e8
      [  160.240106] ESI: c0ed0000 EDI: 00000000 EBP: 080537e8 ESP: bfa13660
      [  160.240106]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
      [  160.240106] Code: 59 8b 00 a8 01 0f 84 09 01 00 00 8b 07 66 25 00 f0 66 3d 00 80 75 61 89 f8 e8 3e e2 ff ff 84 c0 74 56 83 bf 48 02 00 00 00 75 02 <0f> 0b 81 7d e8 00 10 00 00 74 02 0f 0b 8b 43 04 8b 53 08 31 c9
      [  160.240106] EIP: ext4_block_zero_page_range+0x1a7/0x2b4 SS:ESP: 0068:f47b7dac
      [  160.317241] ---[ end trace d6a773a375c810a5 ]---
      
      The problem is that when the kernel tries to truncate an inode in
      ext4_truncate(), it tries to clear any on-disk data beyond i_size.
      Without the encryption key, it can't do that, and so it triggers a
      BUG.
      
      E2fsck does *not* provide this service, and in practice most file
      systems have their orphan list processed by e2fsck, so to avoid
      crashing, this patch skips this step if we don't have access to the
      encryption key (which is the case when processing the orphan list; in
      all other cases, we will have the encryption key, or the kernel
      wouldn't have allowed the file to be opened).
      
      An open question is whether the fact that e2fsck isn't clearing the
      bytes beyond i_size causing problems --- and if we've lived with it
      not doing it for so long, can we drop this from the kernel replay of
      the orphan list in all cases (not just when we don't have the key for
      encrypted inodes).
      
      Addresses-Google-Bug: #35209576
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc37bb8d
    • Sean Young's avatar
      rc: raw decoder for keymap protocol is not loaded on register · 1cda2908
      Sean Young authored
      commit 41380868 upstream.
      
      When the protocol is set via the sysfs protocols attribute, the
      decoder is loaded. However, when it is not when a device is first
      plugged in or registered.
      
      Fixes: acc1c3c6 ("[media] media: rc: load decoder modules on-demand")
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      1cda2908
    • Mikulas Patocka's avatar
      dm: flush queued bios when process blocks to avoid deadlock · 22fc2f9e
      Mikulas Patocka authored
      commit d67a5f4b upstream.
      
      Commit df2cb6da ("block: Avoid deadlocks with bio allocation by
      stacking drivers") created a workqueue for every bio set and code
      in bio_alloc_bioset() that tries to resolve some low-memory deadlocks
      by redirecting bios queued on current->bio_list to the workqueue if the
      system is low on memory.  However other deadlocks (see below **) may
      happen, without any low memory condition, because generic_make_request
      is queuing bios to current->bio_list (rather than submitting them).
      
      ** the related dm-snapshot deadlock is detailed here:
      https://www.redhat.com/archives/dm-devel/2016-July/msg00065.html
      
      Fix this deadlock by redirecting any bios on current->bio_list to the
      bio_set's rescue workqueue on every schedule() call.  Consequently,
      when the process blocks on a mutex, the bios queued on
      current->bio_list are dispatched to independent workqueus and they can
      complete without waiting for the mutex to be available.
      
      The structure blk_plug contains an entry cb_list and this list can contain
      arbitrary callback functions that are called when the process blocks.
      To implement this fix DM (ab)uses the onstack plug's cb_list interface
      to get its flush_current_bio_list() called at schedule() time.
      
      This fixes the snapshot deadlock - if the map method blocks,
      flush_current_bio_list() will be called and it redirects bios waiting
      on current->bio_list to appropriate workqueues.
      
      Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1267650
      Depends-on: df2cb6da ("block: Avoid deadlocks with bio allocation by stacking drivers")
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      22fc2f9e
    • Sean Young's avatar
      serial_ir: ensure we're ready to receive interrupts · 2030aedc
      Sean Young authored
      commit 0265634e upstream.
      
      When the interrupt requested with devm_request_irq(), serial_ir.rcdev
      is still null so will cause null deference if the irq handler is called
      early on.
      
      Also ensure that timeout_timer is setup.
      
      Link: http://lkml.kernel.org/r/CA+55aFxsh2uF8gi5sN_guY3Z+tiLv7LpJYKBw+y8vqLzp+TsnQ@mail.gmail.com
      
      [mchehab@s-opensource.com: moved serial_ir_probe() back to its original place]
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2030aedc
    • Takashi Iwai's avatar
      drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env var · 81383a00
      Takashi Iwai authored
      commit d8e9b2b9 upstream.
      
      send_display_send_uevent() sends two environment variable, and the
      first one GVT_DISPLAY_READY is set including a new line at the end of
      the string; that is obviously superfluous and wrong -- at least, it
      *looks* so when you only read the code.
      
      However, it doesn't appear in the actual output by a (supposedly
      unexpected) trick.  The code uses snprintf() and truncates the string
      in size 20 bytes.  This makes the string as GVT_DISPLAY_READY=0 or
      ...=1 including the trailing NUL-letter.  That is, the '\n' found in
      the format string is always cut off as a result.
      
      Although the code gives the correct result, it is confusing.  This
      patch addresses it, just removing the superfluous '\n' from the format
      string for avoiding further confusion.  If the argument "ready" were
      not a  bool, the size 20 should be corrected as well.  But it's a
      bool, so we can leave the magic number 20 as is for now.
      
      FWIW, the bug was spotted by a new GCC7 warning:
        drivers/gpu/drm/i915/gvt/handlers.c: In function 'pvinfo_mmio_write':
        drivers/gpu/drm/i915/gvt/handlers.c:1042:34: error: 'snprintf' output truncated before the last format character [-Werror=format-truncation=]
          snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
                                          ^~~~~~~~~~~~~~~~~~~~~~~~
        drivers/gpu/drm/i915/gvt/handlers.c:1042:2: note: 'snprintf' output 21 bytes into a destination of size 20
          snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Fixes: 04d348ae ("drm/i915/gvt: vGPU display virtualization")
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1025903Reported-by: default avatarRichard Biener <rguenther@suse.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81383a00
    • Jintack Lim's avatar
      KVM: arm/arm64: Let vcpu thread modify its own active state · 523379cd
      Jintack Lim authored
      commit 370a0ec1 upstream.
      
      Currently, if a vcpu thread tries to change the active state of an
      interrupt which is already on the same vcpu's AP list, it will loop
      forever. Since the VGIC mmio handler is called after a vcpu has
      already synced back the LR state to the struct vgic_irq, we can just
      let it proceed safely.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarJintack Lim <jintack@cs.columbia.edu>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      523379cd
    • Janosch Frank's avatar
      KVM: s390: Fix guest migration for huge guests resulting in panic · 1f9175b9
      Janosch Frank authored
      commit 2e4d8800 upstream.
      
      While we can technically not run huge page guests right now, we can
      setup a guest with huge pages. Trying to migrate it will trigger a
      VM_BUG_ON and, if the kernel is not configured to panic on a BUG, it
      will happily try to work on non-existing page table entries.
      
      With this patch, we always return "dirty" if we encounter a large page
      when migrating. This at least fixes the immediate problem until we
      have proper handling for both kind of pages.
      
      Fixes: 15f36ebd ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
      Signed-off-by: default avatarJanosch Frank <frankja@linux.vnet.ibm.com>
      Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f9175b9
    • Krzysztof Kozlowski's avatar
      serial: samsung: Continue to work if DMA request fails · 45dc259a
      Krzysztof Kozlowski authored
      commit f98c7bce upstream.
      
      If DMA is not available (even when configured in DeviceTree), the driver
      will fail the startup procedure thus making serial console not
      available.
      
      For example this causes boot failure on QEMU ARMv7 (Exynos4210, SMDKC210):
          [    1.302575] OF: amba_device_add() failed (-19) for /amba/pdma@12680000
          ...
          [   11.435732] samsung-uart 13800000.serial: DMA request failed
          [   72.963893] samsung-uart 13800000.serial: DMA request failed
          [   73.143361] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
      
      DMA is not necessary for serial to work, so continue with UART startup
      after emitting a warning.
      
      Fixes: 62c37eed ("serial: samsung: add dma reqest/release functions")
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      45dc259a
    • Johan Hovold's avatar
      USB: serial: io_ti: fix information leak in completion handler · 7daf817d
      Johan Hovold authored
      commit 654b404f upstream.
      
      Add missing sanity check to the bulk-in completion handler to avoid an
      integer underflow that can be triggered by a malicious device.
      
      This avoids leaking 128 kB of memory content from after the URB transfer
      buffer to user space.
      
      Fixes: 8c209e67 ("USB: make actual_length in struct urb field u32")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7daf817d
    • Johan Hovold's avatar
      USB: serial: io_ti: fix NULL-deref in interrupt callback · 9bb084c7
      Johan Hovold authored
      commit 0b1d250a upstream.
      
      Fix a NULL-pointer dereference in the interrupt callback should a
      malicious device send data containing a bad port number by adding the
      missing sanity check.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9bb084c7
    • Johan Hovold's avatar
      USB: iowarrior: fix NULL-deref in write · 14bca59b
      Johan Hovold authored
      commit de46e566 upstream.
      
      Make sure to verify that we have the required interrupt-out endpoint for
      IOWarrior56 devices to avoid dereferencing a NULL-pointer in write
      should a malicious device lack such an endpoint.
      
      Fixes: 946b960d ("USB: add driver for iowarrior devices.")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14bca59b
    • Johan Hovold's avatar
      USB: iowarrior: fix NULL-deref at probe · 5ec59765
      Johan Hovold authored
      commit b7321e81 upstream.
      
      Make sure to check for the required interrupt-in endpoint to avoid
      dereferencing a NULL-pointer should a malicious device lack such an
      endpoint.
      
      Note that a fairly recent change purported to fix this issue, but added
      an insufficient test on the number of endpoints only, a test which can
      now be removed.
      
      Fixes: 4ec0ef3a ("USB: iowarrior: fix oops with malicious USB descriptors")
      Fixes: 946b960d ("USB: add driver for iowarrior devices.")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ec59765
    • Johan Hovold's avatar
      USB: serial: omninet: fix reference leaks at open · cc6ba470
      Johan Hovold authored
      commit 30572418 upstream.
      
      This driver needlessly took another reference to the tty on open, a
      reference which was then never released on close. This lead to not just
      a leak of the tty, but also a driver reference leak that prevented the
      driver from being unloaded after a port had once been opened.
      
      Fixes: 4a90f09b ("tty: usb-serial krefs")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc6ba470
    • Johan Hovold's avatar
      USB: serial: safe_serial: fix information leak in completion handler · dc944b11
      Johan Hovold authored
      commit 8c76d7cd upstream.
      
      Add missing sanity check to the bulk-in completion handler to avoid an
      integer underflow that could be triggered by a malicious device.
      
      This avoids leaking up to 56 bytes from after the URB transfer buffer to
      user space.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc944b11
    • Guenter Roeck's avatar
      usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers · a062cb39
      Guenter Roeck authored
      commit dcc7620c upstream.
      
      Upstream commit 98d74f9c ("xhci: fix 10 second timeout on removal of
      PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI
      xhci controllers which can result in excessive timeouts, to the point where
      the system reports a deadlock.
      
      The same problem is seen with hot pluggable xhci controllers using the
      xhci-plat driver, such as the driver used for Type-C ports on rk3399.
      Similar to hot-pluggable PCI controllers, the driver for this chip
      removes the xhci controller from the system when the Type-C cable is
      disconnected.
      
      The solution for PCI devices works just as well for non-PCI devices
      and avoids the problem.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a062cb39
    • Peter Chen's avatar
      usb: host: xhci-dbg: HCIVERSION should be a binary number · 72023536
      Peter Chen authored
      commit f95e60a7 upstream.
      
      According to xHCI spec, HCIVERSION containing a BCD encoding
      of the xHCI specification revision number, 0100h corresponds
      to xHCI version 1.0. Change "100" as "0x100".
      
      Cc: Lu Baolu <baolu.lu@linux.intel.com>
      Fixes: 04abb6de ("xhci: Read and parse new xhci 1.1 capability register")
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72023536
    • Roger Quadros's avatar
      Revert "usb: gadget: uvc: Add missing call for additional setup data" · 222095ea
      Roger Quadros authored
      commit eb38d913 upstream.
      
      This reverts commit 4fbac520.
      
      This commit breaks g_webcam when used with uvc-gadget [1].
      
      The user space application (e.g. uvc-gadget) is responsible for
      sending response to UVC class specific requests on control endpoint
      in uvc_send_response() in uvc_v4l2.c.
      
      The bad commit was causing a duplicate response to be sent with
      incorrect response data thus causing UVC probe to fail at the host
      and broken control transfer endpoint at the gadget.
      
      [1] - git://git.ideasonboard.org/uvc-gadget.gitAcked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      222095ea
    • Felipe Balbi's avatar
      usb: gadget: function: f_fs: pass companion descriptor along · d60b1053
      Felipe Balbi authored
      commit 2bfa0719 upstream.
      
      If we're dealing with SuperSpeed endpoints, we need
      to make sure to pass along the companion descriptor
      and initialize fields needed by the Gadget
      API. Eventually, f_fs.c should be converted to use
      config_ep_by_speed() like all other functions,
      though.
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d60b1053
    • Jelle Martijn Kok's avatar
      usb: ohci-at91: Do not drop unhandled USB suspend control requests · a0f69738
      Jelle Martijn Kok authored
      commit 85550f91 upstream.
      
      In patch 2e2aa1bcm, USB suspend and wakeup control requests are
      passed to SFR_OHCIICR register. If a processor does not have such a
      register, this hub control request will be dropped.
      
      If no such a SFR register is available, all USB suspend control requests
      will now be processed using ohci_hub_control()
      (like before patch 2e2aa1bcm.)
      
      Tested on an Atmel AT91SAM9G20 with an on-board TI TUSB2046B hub chip
      If the last USB device is unplugged from the USB hub, the hub goes into
      sleep and will not wakeup when an USB devices is inserted.
      
      Fixes: 2e2aa1bc ("usb: ohci-at91: Forcibly suspend ports while USB suspend")
      Signed-off-by: default avatarJelle Martijn Kok <jmkok@youcom.nl>
      Tested-by: default avatarWenyou Yang <wenyou.yang@atmel.com>
      Cc: Wenyou Yang <wenyou.yang@atmel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Reviewed-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0f69738
    • Roger Quadros's avatar
      usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox() · 25b1a4fd
      Roger Quadros authored
      commit 0913750f upstream.
      
      We need to break from all cases if we want to treat
      each one of them separately.
      Reported-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Fixes: d2728fb3 ("usb: dwc3: omap: Pass VBUS and ID events transparently")
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      25b1a4fd
    • Felipe Balbi's avatar
      usb: dwc3: gadget: make Set Endpoint Configuration macros safe · 894a0dfa
      Felipe Balbi authored
      commit 7369090a upstream.
      
      Some gadget drivers are bad, bad boys. We notice
      that ADB was passing bad Burst Size which caused top
      bits of param0 to be overwritten which confused DWC3
      when running this command.
      
      In order to avoid future issues, we're going to make
      sure values passed by macros are always safe for the
      controller. Note that ADB still needs a fix to *not*
      pass bad values.
      Reported-by: default avatarMohamed Abbas <mohamed.abbas@intel.com>
      Sugested-by: default avatarAdam Andruszak <adam.andruszak@intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      894a0dfa
    • Peter Chen's avatar
      usb: gadget: dummy_hcd: clear usb_gadget region before registration · c73210fd
      Peter Chen authored
      commit 5bbc8526 upstream.
      
      When the user does device unbind and rebind test, the kernel will
      show below dump due to usb_gadget memory region is dirty after unbind.
      Clear usb_gadget region for every new probe.
      
      root@imx6qdlsolo:/sys/bus/platform/drivers/dummy_udc# echo dummy_udc.0 > bind
      [  102.523312] kobject (eddd78b0): tried to init an initialized object, something is seriously wrong.
      [  102.532447] CPU: 0 PID: 734 Comm: sh Not tainted 4.10.0-rc7-00872-g1b2b8e9 #1298
      [  102.539866] Hardware name: Freescale i.MX6 SoloX (Device Tree)
      [  102.545717] Backtrace:
      [  102.548225] [<c010d090>] (dump_backtrace) from [<c010d338>] (show_stack+0x18/0x1c)
      [  102.555822]  r7:ede34000 r6:60010013 r5:00000000 r4:c0f29418
      [  102.561512] [<c010d320>] (show_stack) from [<c040c2a4>] (dump_stack+0xb4/0xe8)
      [  102.568764] [<c040c1f0>] (dump_stack) from [<c040e6d4>] (kobject_init+0x80/0x9c)
      [  102.576187]  r10:0000001f r9:eddd7000 r8:eeaf8c10 r7:eddd78a8 r6:c177891c r5:c0f3b060
      [  102.584036]  r4:eddd78b0 r3:00000000
      [  102.587641] [<c040e654>] (kobject_init) from [<c05359a4>] (device_initialize+0x28/0xf8)
      [  102.595665]  r5:eebc4800 r4:eddd78a8
      [  102.599268] [<c053597c>] (device_initialize) from [<c05382ac>] (device_register+0x14/0x20)
      [  102.607556]  r7:eddd78a8 r6:00000000 r5:eebc4800 r4:eddd78a8
      [  102.613256] [<c0538298>] (device_register) from [<c0668ef4>] (usb_add_gadget_udc_release+0x8c/0x1ec)
      [  102.622410]  r5:eebc4800 r4:eddd7860
      [  102.626015] [<c0668e68>] (usb_add_gadget_udc_release) from [<c0669068>] (usb_add_gadget_udc+0x14/0x18)
      [  102.635351]  r10:0000001f r9:eddd7000 r8:eddd788c r7:bf003770 r6:eddd77f8 r5:eddd7818
      [  102.643198]  r4:eddd785c r3:eddd7b24
      [  102.646834] [<c0669054>] (usb_add_gadget_udc) from [<bf003428>] (dummy_udc_probe+0x170/0x1c4 [dummy_hcd])
      [  102.656458] [<bf0032b8>] (dummy_udc_probe [dummy_hcd]) from [<c053d114>] (platform_drv_probe+0x54/0xb8)
      [  102.665881]  r10:00000008 r9:c1778960 r8:bf004128 r7:fffffdfb r6:bf004128 r5:eeaf8c10
      [  102.673727]  r4:eeaf8c10
      [  102.676293] [<c053d0c0>] (platform_drv_probe) from [<c053b160>] (driver_probe_device+0x264/0x474)
      [  102.685186]  r7:00000000 r6:00000000 r5:c1778960 r4:eeaf8c10
      [  102.690876] [<c053aefc>] (driver_probe_device) from [<c05397c4>] (bind_store+0xb8/0x14c)
      [  102.698994]  r10:eeb3bb4c r9:ede34000 r8:0000000c r7:eeaf8c44 r6:bf004128 r5:c0f3b668
      [  102.706840]  r4:eeaf8c10
      [  102.709402] [<c053970c>] (bind_store) from [<c0538ca8>] (drv_attr_store+0x28/0x34)
      [  102.716998]  r9:ede34000 r8:00000000 r7:ee3863c0 r6:ee3863c0 r5:c0538c80 r4:c053970c
      [  102.724776] [<c0538c80>] (drv_attr_store) from [<c029c930>] (sysfs_kf_write+0x50/0x54)
      [  102.732711]  r5:c0538c80 r4:0000000c
      [  102.736313] [<c029c8e0>] (sysfs_kf_write) from [<c029be84>] (kernfs_fop_write+0x100/0x214)
      [  102.744599]  r7:ee3863c0 r6:eeb3bb40 r5:00000000 r4:00000000
      [  102.750287] [<c029bd84>] (kernfs_fop_write) from [<c0222dd8>] (__vfs_write+0x34/0x120)
      [  102.758231]  r10:00000000 r9:ede34000 r8:c0108bc4 r7:0000000c r6:ede35f80 r5:c029bd84
      [  102.766077]  r4:ee223780
      [  102.768638] [<c0222da4>] (__vfs_write) from [<c0224678>] (vfs_write+0xa8/0x170)
      [  102.775974]  r9:ede34000 r8:c0108bc4 r7:ede35f80 r6:01861cb0 r5:ee223780 r4:0000000c
      [  102.783743] [<c02245d0>] (vfs_write) from [<c0225498>] (SyS_write+0x4c/0xa8)
      [  102.790818]  r9:ede34000 r8:c0108bc4 r7:0000000c r6:01861cb0 r5:ee223780 r4:ee223780
      [  102.798595] [<c022544c>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
      [  102.806188]  r7:00000004 r6:b6e83d58 r5:01861cb0 r4:0000000c
      
      Fixes: 90fccb52 ("usb: gadget: Gadget directory cleanup - group UDC drivers")
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Tested-by: default avatarXiaolong Ye <xiaolong.ye@intel.com>
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c73210fd
    • Ethan Zhao's avatar
      PCI: Prevent VPD access for QLogic ISP2722 · b5ea65b2
      Ethan Zhao authored
      commit 0d5370d1 upstream.
      
      QLogic ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter has the VPD
      access issue too, while read the common pci-sysfs access interface shown as
      
       /sys/devices/pci0000:00/0000:00:03.2/0000:0b:00.0/vpd
      
      with simple 'cat' could cause system hang and panic:
      
        Kernel panic - not syncing: An NMI occurred. Depending on your system the reason for the NMI is logged in any one of the following resources:
        1. Integrated Management Log (IML)
        2. OA Syslog
        3. OA Forward Progress Log
        4. iLO Event Log
        CPU: 0 PID: 15070 Comm: udevadm Not tainted 4.1.12
        Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 12/27/2015
         0000000000000086 000000007f0cdf51 ffff880c4fa05d58 ffffffff817193de
         ffffffffa00b42d8 0000000000000075 ffff880c4fa05dd8 ffffffff81714072
         0000000000000008 ffff880c4fa05de8 ffff880c4fa05d88 000000007f0cdf51
        Call Trace:
         <NMI>  [<ffffffff817193de>] dump_stack+0x63/0x81
         [<ffffffff81714072>] panic+0xd0/0x20e
         [<ffffffffa00b390d>] hpwdt_pretimeout+0xdd/0xe0 [hpwdt]
         [<ffffffff81021fc9>] ? sched_clock+0x9/0x10
         [<ffffffff8101c101>] nmi_handle+0x91/0x170
         [<ffffffff8101c10c>] ? nmi_handle+0x9c/0x170
         [<ffffffff8101c5fe>] io_check_error+0x1e/0xa0
         [<ffffffff8101c719>] default_do_nmi+0x99/0x140
         [<ffffffff8101c8b4>] do_nmi+0xf4/0x170
         [<ffffffff817232c5>] end_repeat_nmi+0x1a/0x1e
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         [<ffffffff815d724b>] ? pci_conf1_read+0xeb/0x120
         <<EOE>>  [<ffffffff815db4b3>] raw_pci_read+0x23/0x40
         [<ffffffff815db4fc>] pci_read+0x2c/0x30
         [<ffffffff8136f612>] pci_user_read_config_word+0x72/0x110
         [<ffffffff8136f746>] pci_vpd_pci22_wait+0x96/0x130
         [<ffffffff8136ff9b>] pci_vpd_pci22_read+0xdb/0x1a0
         [<ffffffff8136ea30>] pci_read_vpd+0x20/0x30
         [<ffffffff8137d590>] read_vpd_attr+0x30/0x40
         [<ffffffff8128e037>] sysfs_kf_bin_read+0x47/0x70
         [<ffffffff8128d24e>] kernfs_fop_read+0xae/0x180
         [<ffffffff8120dd97>] __vfs_read+0x37/0x100
         [<ffffffff812ba7e4>] ? security_file_permission+0x84/0xa0
         [<ffffffff8120e366>] ? rw_verify_area+0x56/0xe0
         [<ffffffff8120e476>] vfs_read+0x86/0x140
         [<ffffffff8120f3f5>] SyS_read+0x55/0xd0
         [<ffffffff81720f2e>] system_call_fastpath+0x12/0x71
        Shutting down cpus with NMI
        Kernel Offset: disabled
        drm_kms_helper: panic occurred, switching back to text console
      
      So blacklist the access to its VPD.
      Signed-off-by: default avatarEthan Zhao <ethan.zhao@oracle.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5ea65b2
    • Balbir Singh's avatar
      powerpc/xics: Work around limitations of OPAL XICS priority handling · 27469baa
      Balbir Singh authored
      commit a69e2fb7 upstream.
      
      The CPPR (Current Processor Priority Register) of a XICS interrupt
      presentation controller contains a value N, such that only interrupts
      with a priority "more favoured" than N will be received by the CPU,
      where "more favoured" means "less than". So if the CPPR has the value 5
      then only interrupts with a priority of 0-4 inclusive will be received.
      
      In theory the CPPR can support a value of 0 to 255 inclusive.
      In practice Linux only uses values of 0, 4, 5 and 0xff. Setting the CPPR
      to 0 rejects all interrupts, setting it to 0xff allows all interrupts.
      The values 4 and 5 are used to differentiate IPIs from external
      interrupts. Setting the CPPR to 5 allows IPIs to be received but not
      external interrupts.
      
      The CPPR emulation in the OPAL XICS implementation only directly
      supports priorities 0 and 0xff. All other priorities are considered
      equivalent, and mapped to a single priority value internally. This means
      when using icp-opal we can not allow IPIs but not externals.
      
      This breaks Linux's use of priority values when a CPU is hot unplugged.
      After migrating IRQs away from the CPU that is being offlined, we set
      the priority to 5, meaning we still want the offline CPU to receive
      IPIs. But the effect of the OPAL XICS emulation's use of a single
      priority value is that all interrupts are rejected by the CPU. With the
      CPU offline, and not receiving IPIs, we may not be able to wake it up to
      bring it back online.
      
      The first part of the fix is in icp_opal_set_cpu_priority(). CPPR values
      of 0 to 4 inclusive will correctly cause all interrupts to be rejected,
      so we pass those CPPR values through to OPAL. However if we are called
      with a CPPR of 5 or greater, the caller is expecting to be able to allow
      IPIs but not external interrupts. We know this doesn't work, so instead
      of rejecting all interrupts we choose the opposite which is to allow all
      interrupts. This is still not correct behaviour, but we know for the
      only existing caller (xics_migrate_irqs_away()), that it is the better
      option.
      
      The other part of the fix is in xics_migrate_irqs_away(). Instead of
      setting priority (CPPR) to 0, and then back to 5 before migrating IRQs,
      we migrate the IRQs before setting the priority back to 5. This should
      have no effect on an ICP backend with a working set_priority(), and on
      icp-opal it means we will keep all interrupts blocked until after we've
      finished doing the IRQ migration. Additionally we wait for 5ms after
      doing the migration to make sure there are no IRQs in flight.
      
      Fixes: d7436188 ("powerpc/xics: Add ICP OPAL backend")
      Suggested-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reported-by: default avatarVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Tested-by: default avatarVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Signed-off-by: default avatarBalbir Singh <bsingharora@gmail.com>
      [mpe: Rewrote comments and change log, change delay to 5ms]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27469baa
    • Laurentiu Tudor's avatar
      powerpc/booke: Fix boot crash due to null hugepd · 74e236a5
      Laurentiu Tudor authored
      commit 3fb66a70 upstream.
      
      On 32-bit book-e machines, hugepd_ok() no longer takes into account null
      hugepd values, causing this crash at boot:
      
        Unable to handle kernel paging request for data at address 0x80000000
        ...
        NIP [c0018378] follow_huge_addr+0x38/0xf0
        LR [c001836c] follow_huge_addr+0x2c/0xf0
        Call Trace:
         follow_huge_addr+0x2c/0xf0 (unreliable)
         follow_page_mask+0x40/0x3e0
         __get_user_pages+0xc8/0x450
         get_user_pages_remote+0x8c/0x250
         copy_strings+0x110/0x390
         copy_strings_kernel+0x2c/0x50
         do_execveat_common+0x478/0x630
         do_execve+0x2c/0x40
         try_to_run_init_process+0x18/0x60
         kernel_init+0xbc/0x110
         ret_from_kernel_thread+0x5c/0x64
      
      This impacts all nxp (ex-freescale) 32-bit booke platforms.
      
      This was caused by the change of hugepd_t.pd from signed to unsigned,
      and the update to the nohash version of hugepd_ok(). Previously
      hugepd_ok() could exclude all non-huge and NULL pgds using > 0, whereas
      now we need to explicitly check that the value is not zero and also that
      PD_HUGE is *clear*.
      
      This isn't protected by the pgd_none() check in __find_linux_pte_or_hugepte()
      because on 32-bit we use pgtable-nopud.h, which causes the pgd_none()
      check to be always false.
      
      Fixes: 20717e1f ("powerpc/mm: Fix little-endian 4K hugetlb")
      Reported-by: default avatarMadalin-Cristian Bucur <madalin.bucur@nxp.com>
      Signed-off-by: default avatarLaurentiu Tudor <laurentiu.tudor@nxp.com>
      [mpe: Flesh out change log details.]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74e236a5
    • Ravi Bangoria's avatar
      powerpc: Emulation support for load/store instructions on LE · 1006828d
      Ravi Bangoria authored
      commit e148bd17 upstream.
      
      emulate_step() uses a number of underlying kernel functions that were
      initially not enabled for LE. This has been rectified since. So, fix
      emulate_step() for LE for the corresponding instructions.
      Reported-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1006828d
    • Qi Hou's avatar
      i2c: add missing of_node_put in i2c_mux_del_adapters · 80eae855
      Qi Hou authored
      commit 2e1e4949 upstream.
      
      Refcount of of_node is increased with of_node_get() in i2c_mux_add_adapter().
      It must be decreased with of_node_put() in i2c_mux_del_adapters().
      Signed-off-by: default avatarQi Hou <qi.hou@windriver.com>
      Reviewed-by: default avatarZhang Xiao <xiao.zhang@windriver.com>
      Signed-off-by: default avatarPeter Rosin <peda@axentia.se>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80eae855
    • Jonathan McDowell's avatar
      dw2102: don't do DMA on stack · be20197d
      Jonathan McDowell authored
      commit 606142af upstream.
      
      On Kernel 4.9, WARNINGs about doing DMA on stack are hit at
      the dw2102 driver: one in su3000_power_ctrl() and the other in tt_s2_4600_frontend_attach().
      
      Both were due to the use of buffers on the stack as parameters to
      dvb_usb_generic_rw() and the resulting attempt to do DMA with them.
      
      The device was non-functional as a result.
      
      So, switch this driver over to use a buffer within the device state
      structure, as has been done with other DVB-USB drivers.
      
      Tested with TechnoTrend TT-connect S2-4600.
      
      [mchehab@osg.samsung.com: fixed a warning at su3000_i2c_transfer() that
       state var were dereferenced before check 'd']
      Signed-off-by: default avatarJonathan McDowell <noodles@earth.li>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be20197d