1. 17 Jun, 2017 6 commits
    • Linus Torvalds's avatar
      Merge tag 'usb-4.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · 19ea9d66
      Linus Torvalds authored
      Pull USB fixes from Greg KH:
       "Here are some small gadget and xhci USB fixes for 4.12-rc6.
      
        Nothing major, but one of the gadget patches does fix a reported oops,
        and the xhci ones resolve reported problems. All have been in
        linux-next with no reported issues"
      
      * tag 'usb-4.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
        USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
        usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk
        usb: xhci: Fix USB 3.1 supported protocol parsing
        USB: gadget: fix GPF in gadgetfs
        usb: gadget: composite: make sure to reactivate function on unbind
      19ea9d66
    • Linus Torvalds's avatar
      Merge tag 'staging-4.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · 1be627df
      Linus Torvalds authored
      Pull staging and IIO fixes from Greg KH:
       "Here are some small staging and IIO driver fixes for 4.12-rc6.
      
        Nothing huge, just a few small driver fixes for reported issues. All
        have been in linux-next with no reported issues"
      
      * tag 'staging-4.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        Staging: rtl8723bs: fix an error code in isFileReadable()
        iio: buffer-dmaengine: Add missing header buffer_impl.h
        iio: buffer-dma: Add missing header buffer_impl.h
        iio: adc: meson-saradc: fix potential crash in meson_sar_adc_clear_fifo
        iio: adc: mxs-lradc: Fix return value check in mxs_lradc_adc_probe()
        iio: imu: inv_mpu6050: add accel lpf setting for chip >= MPU6500
        staging: iio: ad7152: Fix deadlock in ad7152_write_raw_samp_freq()
      1be627df
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-4.12-rc6' of git://github.com/ceph/ceph-client · 6e203506
      Linus Torvalds authored
      Pull ceph fixes from Ilya Dryomov:
       "A fix for an old ceph ->fh_to_* bug from Luis and two timestamp fixups
        from Zheng, prompted by the ongoing y2038 work"
      
      * tag 'ceph-for-4.12-rc6' of git://github.com/ceph/ceph-client:
        ceph: unify inode i_ctime update
        ceph: use current_kernel_time() to get request time stamp
        ceph: check i_nlink while converting a file handle to dentry
      6e203506
    • Linus Torvalds's avatar
      Merge tag 'xfs-4.12-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · adc31103
      Linus Torvalds authored
      Pull xfs fix from Darrick Wong:
       "One more bugfix for you for 4.12-rc6 to fix something that came up in
        an earlier rc:
      
         - Fix some bogus ASSERT failures on CONFIG_SMP=n and CONFIG_XFS_DEBUG=y"
      
      * tag 'xfs-4.12-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: fix spurious spin_is_locked() assert failures on non-smp kernels
      adc31103
    • Linus Torvalds's avatar
      Merge branch 'ufs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · c8636b90
      Linus Torvalds authored
      Pull ufs fixes from Al Viro:
       "Fix assorted ufs bugs: a couple of deadlocks, fs corruption in
        truncate(), oopsen on tail unpacking and truncate when racing with
        vmscan, mild fs corruption (free blocks stats summary buggered, *BSD
        fsck would complain and fix), several instances of broken logics
        around reserved blocks (starting with "check almost never triggers
        when it should" and then there are issues with sufficiently large
        UFS2)"
      
      [ Note: ufs hasn't gotten any loving in a long time, because nobody
        really seems to use it. These ufs fixes are triggered by people
        actually caring now, not some sudden influx of new bugs.  - Linus ]
      
      * 'ufs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        ufs_truncate_blocks(): fix the case when size is in the last direct block
        ufs: more deadlock prevention on tail unpacking
        ufs: avoid grabbing ->truncate_mutex if possible
        ufs_get_locked_page(): make sure we have buffer_heads
        ufs: fix s_size/s_dsize users
        ufs: fix reserved blocks check
        ufs: make ufs_freespace() return signed
        ufs: fix logics in "ufs: make fsck -f happy"
      c8636b90
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · ccd3d905
      Linus Torvalds authored
      Pull vfs fixes from Al Viro:
       "A couple of fixes; a leak in mntns_install() caught by Andrei (this
        cycle regression) + d_invalidate() softlockup fix - that had been
        reported by a bunch of people lately, but the problem is pretty old"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        fs: don't forget to put old mntns in mntns_install
        Hang/soft lockup in d_invalidate with simultaneous calls
      ccd3d905
  2. 16 Jun, 2017 22 commits
  3. 15 Jun, 2017 12 commits
    • Alan Stern's avatar
      USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks · f16443a0
      Alan Stern authored
      Using the syzkaller kernel fuzzer, Andrey Konovalov generated the
      following error in gadgetfs:
      
      > BUG: KASAN: use-after-free in __lock_acquire+0x3069/0x3690
      > kernel/locking/lockdep.c:3246
      > Read of size 8 at addr ffff88003a2bdaf8 by task kworker/3:1/903
      >
      > CPU: 3 PID: 903 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #35
      > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      > Workqueue: usb_hub_wq hub_event
      > Call Trace:
      >  __dump_stack lib/dump_stack.c:16 [inline]
      >  dump_stack+0x292/0x395 lib/dump_stack.c:52
      >  print_address_description+0x78/0x280 mm/kasan/report.c:252
      >  kasan_report_error mm/kasan/report.c:351 [inline]
      >  kasan_report+0x230/0x340 mm/kasan/report.c:408
      >  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:429
      >  __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246
      >  lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
      >  __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
      >  _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
      >  spin_lock include/linux/spinlock.h:299 [inline]
      >  gadgetfs_suspend+0x89/0x130 drivers/usb/gadget/legacy/inode.c:1682
      >  set_link_state+0x88e/0xae0 drivers/usb/gadget/udc/dummy_hcd.c:455
      >  dummy_hub_control+0xd7e/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2074
      >  rh_call_control drivers/usb/core/hcd.c:689 [inline]
      >  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
      >  usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
      >  usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
      >  usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
      >  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
      >  usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
      >  usb_clear_port_feature+0x74/0xa0 drivers/usb/core/hub.c:412
      >  hub_port_disable+0x123/0x510 drivers/usb/core/hub.c:4177
      >  hub_port_init+0x1ed/0x2940 drivers/usb/core/hub.c:4648
      >  hub_port_connect drivers/usb/core/hub.c:4826 [inline]
      >  hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
      >  port_event drivers/usb/core/hub.c:5105 [inline]
      >  hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
      >  process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
      >  process_scheduled_works kernel/workqueue.c:2157 [inline]
      >  worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
      >  kthread+0x363/0x440 kernel/kthread.c:231
      >  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424
      >
      > Allocated by task 9958:
      >  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
      >  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
      >  set_track mm/kasan/kasan.c:525 [inline]
      >  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
      >  kmem_cache_alloc_trace+0x87/0x280 mm/slub.c:2745
      >  kmalloc include/linux/slab.h:492 [inline]
      >  kzalloc include/linux/slab.h:665 [inline]
      >  dev_new drivers/usb/gadget/legacy/inode.c:170 [inline]
      >  gadgetfs_fill_super+0x24f/0x540 drivers/usb/gadget/legacy/inode.c:1993
      >  mount_single+0xf6/0x160 fs/super.c:1192
      >  gadgetfs_mount+0x31/0x40 drivers/usb/gadget/legacy/inode.c:2019
      >  mount_fs+0x9c/0x2d0 fs/super.c:1223
      >  vfs_kern_mount.part.25+0xcb/0x490 fs/namespace.c:976
      >  vfs_kern_mount fs/namespace.c:2509 [inline]
      >  do_new_mount fs/namespace.c:2512 [inline]
      >  do_mount+0x41b/0x2d90 fs/namespace.c:2834
      >  SYSC_mount fs/namespace.c:3050 [inline]
      >  SyS_mount+0xb0/0x120 fs/namespace.c:3027
      >  entry_SYSCALL_64_fastpath+0x1f/0xbe
      >
      > Freed by task 9960:
      >  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
      >  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
      >  set_track mm/kasan/kasan.c:525 [inline]
      >  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
      >  slab_free_hook mm/slub.c:1357 [inline]
      >  slab_free_freelist_hook mm/slub.c:1379 [inline]
      >  slab_free mm/slub.c:2961 [inline]
      >  kfree+0xed/0x2b0 mm/slub.c:3882
      >  put_dev+0x124/0x160 drivers/usb/gadget/legacy/inode.c:163
      >  gadgetfs_kill_sb+0x33/0x60 drivers/usb/gadget/legacy/inode.c:2027
      >  deactivate_locked_super+0x8d/0xd0 fs/super.c:309
      >  deactivate_super+0x21e/0x310 fs/super.c:340
      >  cleanup_mnt+0xb7/0x150 fs/namespace.c:1112
      >  __cleanup_mnt+0x1b/0x20 fs/namespace.c:1119
      >  task_work_run+0x1a0/0x280 kernel/task_work.c:116
      >  exit_task_work include/linux/task_work.h:21 [inline]
      >  do_exit+0x18a8/0x2820 kernel/exit.c:878
      >  do_group_exit+0x14e/0x420 kernel/exit.c:982
      >  get_signal+0x784/0x1780 kernel/signal.c:2318
      >  do_signal+0xd7/0x2130 arch/x86/kernel/signal.c:808
      >  exit_to_usermode_loop+0x1ac/0x240 arch/x86/entry/common.c:157
      >  prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
      >  syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
      >  entry_SYSCALL_64_fastpath+0xbc/0xbe
      >
      > The buggy address belongs to the object at ffff88003a2bdae0
      >  which belongs to the cache kmalloc-1024 of size 1024
      > The buggy address is located 24 bytes inside of
      >  1024-byte region [ffff88003a2bdae0, ffff88003a2bdee0)
      > The buggy address belongs to the page:
      > page:ffffea0000e8ae00 count:1 mapcount:0 mapping:          (null)
      > index:0x0 compound_mapcount: 0
      > flags: 0x100000000008100(slab|head)
      > raw: 0100000000008100 0000000000000000 0000000000000000 0000000100170017
      > raw: ffffea0000ed3020 ffffea0000f5f820 ffff88003e80efc0 0000000000000000
      > page dumped because: kasan: bad access detected
      >
      > Memory state around the buggy address:
      >  ffff88003a2bd980: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >  ffff88003a2bda00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      > >ffff88003a2bda80: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb
      >                                                                 ^
      >  ffff88003a2bdb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >  ffff88003a2bdb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      > ==================================================================
      
      What this means is that the gadgetfs_suspend() routine was trying to
      access dev->lock after it had been deallocated.  The root cause is a
      race in the dummy_hcd driver; the dummy_udc_stop() routine can race
      with the rest of the driver because it contains no locking.  And even
      when proper locking is added, it can still race with the
      set_link_state() function because that function incorrectly drops the
      private spinlock before invoking any gadget driver callbacks.
      
      The result of this race, as seen above, is that set_link_state() can
      invoke a callback in gadgetfs even after gadgetfs has been unbound
      from dummy_hcd's UDC and its private data structures have been
      deallocated.
      
      include/linux/usb/gadget.h documents that the ->reset, ->disconnect,
      ->suspend, and ->resume callbacks may be invoked in interrupt context.
      In general this is necessary, to prevent races with gadget driver
      removal.  This patch fixes dummy_hcd to retain the spinlock across
      these calls, and it adds a spinlock acquisition to dummy_udc_stop() to
      prevent the race.
      
      The net2280 driver makes the same mistake of dropping the private
      spinlock for its ->disconnect and ->reset callback invocations.  The
      patch fixes it too.
      
      Lastly, since gadgetfs_suspend() may be invoked in interrupt context,
      it cannot assume that interrupts are enabled when it runs.  It must
      use spin_lock_irqsave() instead of spin_lock_irq().  The patch fixes
      that bug as well.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f16443a0
    • Fabio Estevam's avatar
      drm: mxsfb_crtc: Reset the eLCDIF controller · 0f933328
      Fabio Estevam authored
      According to the eLCDIF initialization steps listed in the MX6SX
      Reference Manual the eLCDIF block reset is mandatory.
      
      Without performing the eLCDIF reset the display shows garbage content
      when the kernel boots.
      
      In earlier tests this issue has not been observed because the bootloader
      was previously showing a splash screen and the bootloader display driver
      does properly implement the eLCDIF reset.
      
      Add the eLCDIF reset to the driver, so that it can operate correctly
      independently of the bootloader.
      
      Tested on a imx6sx-sdb board.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/1494007301-14535-1-git-send-email-fabio.estevam@nxp.com
      0f933328
    • Mathieu Larouche's avatar
      drm/mgag200: Fix to always set HiPri for G200e4 V2 · 0cbb7381
      Mathieu Larouche authored
        - Changed the HiPri value for G200e4 to always be 0.
        - Added Bandwith limitation to block resolution above 1920x1200x60Hz
      Signed-off-by: default avatarMathieu Larouche <mathieu.larouche@matrox.com>
      Acked-by: default avatarDave Airlie <airlied@redhat.com>
      [seanpaul removed some trailing whitespace from the patch]
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/ec0f8568d7ec41904dfe593c5deccf3f062d7bd8.1497450944.git.mathieu.larouche@matrox.com
      0cbb7381
    • Benjamin Herrenschmidt's avatar
      powerpc/xive: Fix offset for store EOI MMIOs · 25642705
      Benjamin Herrenschmidt authored
      Architecturally we should apply a 0x400 offset for these. Not doing
      it will break future HW implementations.
      
      The offset of 0 is supposed to remain for "triggers" though not all
      sources support both trigger and store EOI, and in P9 specifically,
      some sources will treat 0 as a store EOI. But future chips will not.
      So this makes us use the properly architected offset which should work
      always.
      
      Fixes: 243e2511 ("powerpc/xive: Native exploitation of the XIVE interrupt controller")
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      25642705
    • Dmitry Osipenko's avatar
      drm/tegra: Correct idr_alloc() minimum id · d6c153ec
      Dmitry Osipenko authored
      The client ID 0 is reserved by the host1x/cdma to mark the timeout timer
      work as already been scheduled and context ID is used as the clients one.
      This fixes spurious CDMA timeouts.
      
      Fixes: bdd2f9cd ("drm/tegra: Don't leak kernel pointer to userspace")
      Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Reviewed-by: default avatarMikko Perttunen <mperttunen@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/9c19a44219acd988e678cf9abe21363911184625.1497480754.git.digetx@gmail.com
      d6c153ec
    • Dmitry Osipenko's avatar
      drm/tegra: Fix lockup on a use of staging API · 1066a895
      Dmitry Osipenko authored
      Commit bdd2f9cd ("Don't leak kernel pointer to userspace") added a
      mutex around staging IOCTL's, some of those mutexes are taken twice.
      
      Fixes: bdd2f9cd ("drm/tegra: Don't leak kernel pointer to userspace")
      Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Reviewed-by: default avatarMikko Perttunen <mperttunen@nvidia.com>
      Reviewed-by: default avatarErik Faye-Lund <kusmabite@gmail.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/7b70a506a9d2355ea6ff19a8c4f4d726b67719b3.1497480754.git.digetx@gmail.com
      1066a895
    • Christophe JAILLET's avatar
      gpu: host1x: Fix error handling · 59e04bc2
      Christophe JAILLET authored
      If 'devm_reset_control_get' returns an error, then we erroneously return
      success because error code is taken from 'host->clk' instead of
      'host->rst'.
      
      Fixes: b386c6b7 ("gpu: host1x: Support module reset")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Reviewed-by: default avatarMikko Perttunen <mperttunen@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170410202922.17665-1-christophe.jaillet@wanadoo.fr
      59e04bc2
    • Jean Delvare's avatar
      firmware: dmi_scan: Check DMI structure length · a814c359
      Jean Delvare authored
      Before accessing DMI data to record it for later, we should ensure
      that the DMI structures are large enough to contain the data in
      question.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      a814c359
    • Jean Delvare's avatar
      firmware: dmi: Fix permissions of product_family · e0733e97
      Jean Delvare authored
      This is not sensitive information like serial numbers, we can allow
      all users to read it.
      
      Fix odd alignment while we're here.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Fixes: c61872c9 ("firmware: dmi: Add DMI_PRODUCT_FAMILY identification string")
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      e0733e97
    • Andy Lutomirski's avatar
      firmware: dmi_scan: Make dmi_walk and dmi_walk_early return real error codes · c9268200
      Andy Lutomirski authored
      Currently they return -1 on error, which will confuse callers if
      they try to interpret it as a normal negative error code.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      c9268200
    • Jean Delvare's avatar
      firmware: dmi_scan: Look for SMBIOS 3 entry point first · c9aba143
      Jean Delvare authored
      Since version 3.0.0 of the SMBIOS specification, there can be
      multiple entry points in memory, pointing to one or two DMI tables.
      If both a 32-bit ("_SM_") entry point and a 64-bit ("_SM3_") entry
      point are present, the specification requires that the latter points
      to a table which is a super-set of the table pointed to by the
      former. Therefore we should give preference to the 64-bit ("_SM3_")
      entry point.
      
      However, currently the code is picking the first valid entry point
      it finds. Per specification, we should look for a 64-bit ("_SM3_")
      entry point first, and if we can't find any, look for a 32-bit
      ("_SM_" or "_DMI_") entry point. Modify the code to do that.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      c9aba143
    • Andrei Vagin's avatar
      fs: don't forget to put old mntns in mntns_install · 4068367c
      Andrei Vagin authored
      Fixes: 4f757f3c ("make sure that mntns_install() doesn't end up with referral for root")
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrei Vagin <avagin@openvz.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      4068367c