1. 08 Jun, 2016 28 commits
  2. 01 Jun, 2016 12 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.12 · 351d2d4d
      Greg Kroah-Hartman authored
      351d2d4d
    • Arnd Bergmann's avatar
      kbuild: move -Wunused-const-variable to W=1 warning level · e576ffd9
      Arnd Bergmann authored
      commit c9c6837d upstream.
      
      gcc-6 started warning by default about variables that are not
      used anywhere and that are marked 'const', generating many
      false positives in an allmodconfig build, e.g.:
      
      arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=]
      arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=]
      drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=]
      drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=]
      drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=]
      drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=]
      
      This is similar to the existing -Wunused-but-set-variable warning
      that was added in an earlier release and that we disable by default
      now and only enable when W=1 is set, so it makes sense to do
      the same here. Once we have eliminated the majority of the
      warnings for both, we can put them back into the default list.
      
      We probably want this in backport kernels as well, to allow building
      them with gcc-6 without introducing extra warnings.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e576ffd9
    • Johannes Thumshirn's avatar
      Revert "scsi: fix soft lockup in scsi_remove_target() on module removal" · 9acf5535
      Johannes Thumshirn authored
      commit 305c2e71 upstream.
      
      Now that we've done a more comprehensive fix with the intermediate
      target state we can remove the previous hack introduced with commit
      90a88d6e ("scsi: fix soft lockup in scsi_remove_target() on module
      removal").
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9acf5535
    • Johannes Thumshirn's avatar
      scsi: Add intermediate STARGET_REMOVE state to scsi_target_state · 210588c0
      Johannes Thumshirn authored
      commit f05795d3 upstream.
      
      Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
      running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
      state is only valid in the path from scsi_remove_target() to
      scsi_target_destroy() indicating this target is going to be removed.
      
      This re-fixes the problem introduced in commits bc3f02a7 ("[SCSI]
      scsi_remove_target: fix softlockup regression on hot remove") and
      40998193 ("scsi: restart list search after unlock in
      scsi_remove_target") in a more comprehensive way.
      
      [mkp: Included James' fix for scsi_target_destroy()]
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Fixes: 40998193Reported-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Tested-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarJames Bottomley <jejb@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      210588c0
    • Mikulas Patocka's avatar
      hpfs: implement the show_options method · 7e920411
      Mikulas Patocka authored
      commit 037369b8 upstream.
      
      The HPFS filesystem used generic_show_options to produce string that is
      displayed in /proc/mounts.  However, there is a problem that the options
      may disappear after remount.  If we mount the filesystem with option1
      and then remount it with option2, /proc/mounts should show both option1
      and option2, however it only shows option2 because the whole option
      string is replaced with replace_mount_options in hpfs_remount_fs.
      
      To fix this bug, implement the hpfs_show_options function that prints
      options that are currently selected.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e920411
    • Mikulas Patocka's avatar
      hpfs: fix remount failure when there are no options changed · 5cb3ec3d
      Mikulas Patocka authored
      commit 44d51706 upstream.
      
      Commit ce657611 ("hpfs: kstrdup() out of memory handling") checks if
      the kstrdup function returns NULL due to out-of-memory condition.
      
      However, if we are remounting a filesystem with no change to
      filesystem-specific options, the parameter data is NULL.  In this case,
      kstrdup returns NULL (because it was passed NULL parameter), although no
      out of memory condition exists.  The mount syscall then fails with
      ENOMEM.
      
      This patch fixes the bug.  We fail with ENOMEM only if data is non-NULL.
      
      The patch also changes the call to replace_mount_options - if we didn't
      pass any filesystem-specific options, we don't call
      replace_mount_options (thus we don't erase existing reported options).
      
      Fixes: ce657611 ("hpfs: kstrdup() out of memory handling")
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5cb3ec3d
    • Richard Weinberger's avatar
      UBI: Fix static volume checks when Fastmap is used · 1ba1f094
      Richard Weinberger authored
      commit 1900149c upstream.
      
      Ezequiel reported that he's facing UBI going into read-only
      mode after power cut. It turned out that this behavior happens
      only when updating a static volume is interrupted and Fastmap is
      used.
      
      A possible trace can look like:
      ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
      ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
      CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
      Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
      0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
      ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
      ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
      Call Trace:
      [<ffffffff8140d841>] dump_stack+0x63/0x82
      [<ffffffffa003abf6>] ubi_eba_read_leb+0x486/0x4a0 [ubi]
      [<ffffffffa00453b3>] ubi_check_volume+0x83/0xf0 [ubi]
      [<ffffffffa0039d97>] ubi_open_volume+0x177/0x350 [ubi]
      [<ffffffffa00375d8>] vol_cdev_open+0x58/0xb0 [ubi]
      [<ffffffff8124b08e>] chrdev_open+0xae/0x1d0
      [<ffffffff81243bcf>] do_dentry_open+0x1ff/0x300
      [<ffffffff8124afe0>] ? cdev_put+0x30/0x30
      [<ffffffff81244d36>] vfs_open+0x56/0x60
      [<ffffffff812545f4>] path_openat+0x4f4/0x1190
      [<ffffffff81256621>] do_filp_open+0x91/0x100
      [<ffffffff81263547>] ? __alloc_fd+0xc7/0x190
      [<ffffffff812450df>] do_sys_open+0x13f/0x210
      [<ffffffff812451ce>] SyS_open+0x1e/0x20
      [<ffffffff81a99e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      
      UBI checks static volumes for data consistency and reads the
      whole volume upon first open. If the volume is found erroneous
      users of UBI cannot read from it, but another volume update is
      possible to fix it. The check is performed by running
      ubi_eba_read_leb() on every allocated LEB of the volume.
      For static volumes ubi_eba_read_leb() computes the checksum of all
      data stored in a LEB. To verify the computed checksum it has to read
      the LEB's volume header which stores the original checksum.
      If the volume header is not found UBI treats this as fatal internal
      error and switches to RO mode. If the UBI device was attached via a
      full scan the assumption is correct, the volume header has to be
      present as it had to be there while scanning to get known as mapped.
      If the attach operation happened via Fastmap the assumption is no
      longer correct. When attaching via Fastmap UBI learns the mapping
      table from Fastmap's snapshot of the system state and not via a full
      scan. It can happen that a LEB got unmapped after a Fastmap was
      written to the flash. Then UBI can learn the LEB still as mapped and
      accessing it returns only 0xFF bytes. As UBI is not a FTL it is
      allowed to have mappings to empty PEBs, it assumes that the layer
      above takes care of LEB accounting and referencing.
      UBIFS does so using the LEB property tree (LPT).
      For static volumes UBI blindly assumes that all LEBs are present and
      therefore special actions have to be taken.
      
      The described situation can happen when updating a static volume is
      interrupted, either by a user or a power cut.
      The volume update code first unmaps all LEBs of a volume and then
      writes LEB by LEB. If the sequence of operations is interrupted UBI
      detects this either by the absence of LEBs, no volume header present
      at scan time, or corrupted payload, detected via checksum.
      In the Fastmap case the former method won't trigger as no scan
      happened and UBI automatically thinks all LEBs are present.
      Only by reading data from a LEB it detects that the volume header is
      missing and incorrectly treats this as fatal error.
      To deal with the situation ubi_eba_read_leb() from now on checks
      whether we attached via Fastmap and handles the absence of a
      volume header like a data corruption error.
      This way interrupted static volume updates will correctly get detected
      also when Fastmap is used.
      Reported-by: default avatarEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Tested-by: default avatarEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ba1f094
    • James Hogan's avatar
      SIGNAL: Move generic copy_siginfo() to signal.h · e044b25a
      James Hogan authored
      commit ca9eb49a upstream.
      
      The generic copy_siginfo() is currently defined in
      asm-generic/siginfo.h, after including uapi/asm-generic/siginfo.h which
      defines the generic struct siginfo. However this makes it awkward for an
      architecture to use it if it has to define its own struct siginfo (e.g.
      MIPS and potentially IA64), since it means that asm-generic/siginfo.h
      can only be included after defining the arch-specific siginfo, which may
      be problematic if the arch-specific definition needs definitions from
      uapi/asm-generic/siginfo.h.
      
      It is possible to work around this by first including
      uapi/asm-generic/siginfo.h to get the constants before defining the
      arch-specific siginfo, and include asm-generic/siginfo.h after. However
      uapi headers can't be included by other uapi headers, so that first
      include has to be in an ifdef __kernel__, with the non __kernel__ case
      including the non-UAPI header instead.
      
      Instead of that mess, move the generic copy_siginfo() definition into
      linux/signal.h, which allows an arch-specific uapi/asm/siginfo.h to
      include asm-generic/siginfo.h and define the arch-specific siginfo, and
      for the generic copy_siginfo() to see that arch-specific definition.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Petr Malat <oss@malat.biz>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Christopher Ferris <cferris@google.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/12478/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e044b25a
    • Andreas Noever's avatar
      thunderbolt: Fix double free of drom buffer · b20909f1
      Andreas Noever authored
      commit 2ffa9a5d upstream.
      
      If tb_drom_read() fails, sw->drom is freed but not set to NULL.  sw->drom
      is then freed again in the error path of tb_switch_alloc().
      
      The bug can be triggered by unplugging a thunderbolt device shortly after
      it is detected by the thunderbolt driver.
      
      Clear sw->drom if tb_drom_read() fails.
      
      [bhelgaas: add Fixes:, stable versions of interest]
      Fixes: 343fcb8c ("thunderbolt: Fix nontrivial endpoint devices.")
      Signed-off-by: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Lukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b20909f1
    • Bart Van Assche's avatar
      IB/srp: Fix a debug kernel crash · a0387018
      Bart Van Assche authored
      commit 54f5c9c5 upstream.
      
      Avoid that the following BUG() is triggered against a debug
      kernel:
      
      kernel BUG at include/linux/scatterlist.h:92!
      RIP: 0010:[<ffffffffa0467199>]  [<ffffffffa0467199>] srp_map_idb+0x199/0x1a0 [ib_srp]
      Call Trace:
       [<ffffffffa04685fa>] srp_map_data+0x84a/0x890 [ib_srp]
       [<ffffffffa0469674>] srp_queuecommand+0x1e4/0x610 [ib_srp]
       [<ffffffff813f5a5e>] scsi_dispatch_cmd+0x9e/0x180
       [<ffffffff813f8b07>] scsi_request_fn+0x477/0x610
       [<ffffffff81298ffe>] __blk_run_queue+0x2e/0x40
       [<ffffffff81299070>] blk_delay_work+0x20/0x30
       [<ffffffff81071f07>] process_one_work+0x197/0x480
       [<ffffffff81072239>] worker_thread+0x49/0x490
       [<ffffffff810787ea>] kthread+0xea/0x100
       [<ffffffff8159b632>] ret_from_fork+0x22/0x40
      
      Fixes: f7f7aab1 ("IB/srp: Convert to new registration API")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Cc: Christoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMax Gurtovoy <maxg@mellanox.com>
      Reviewed-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0387018
    • Hui Wang's avatar
      ALSA: hda - Fix headset mic detection problem for one Dell machine · 23bc22aa
      Hui Wang authored
      commit 86c72d1c upstream.
      
      Add the pin configuration value of this machine into the pin_quirk
      table to make DELL1_MIC_NO_PRESENCE apply to this machine.
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23bc22aa
    • Kailang Yang's avatar
      ALSA: hda/realtek - Add support for ALC295/ALC3254 · b217d532
      Kailang Yang authored
      commit 7d727869 upstream.
      
      Add support for ALC295/ALC3254.
      They are simply compatible with ALC225 chip.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b217d532