1. 30 Jul, 2014 19 commits
    • Linus Torvalds's avatar
      Fix gcc-4.9.0 miscompilation of load_balance() in scheduler · 5c8c5c98
      Linus Torvalds authored
      commit 2062afb4 upstream.
      
      Michel Dänzer and a couple of other people reported inexplicable random
      oopses in the scheduler, and the cause turns out to be gcc mis-compiling
      the load_balance() function when debugging is enabled.  The gcc bug
      apparently goes back to gcc-4.5, but slight optimization changes means
      that it now showed up as a problem in 4.9.0 and 4.9.1.
      
      The instruction scheduling problem causes gcc to schedule a spill
      operation to before the stack frame has been created, which in turn can
      corrupt the spilled value if an interrupt comes in.  There may be other
      effects of this bug too, but that's the code generation problem seen in
      Michel's case.
      
      This is fixed in current gcc HEAD, but the workaround as suggested by
      Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
      when compiling the kernel, which disables the gcc code that causes the
      problem.  This can result in slightly worse debug information for
      variable accesses, but that is infinitely preferable to actual code
      generation problems.
      
      Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
      non-debug builds to verify that the debug build would be identical: we
      can do
      
          export GCC_COMPARE_DEBUG=1
      
      to make gcc internally verify that the result of the build is
      independent of the "-g" flag (it will make the compiler build everything
      twice, toggling the debug flag, and compare the results).
      
      Without the "-fno-var-tracking-assignments" option, the build would fail
      (even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
      compare failure.
      
      See also gcc bugzilla:
      
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801Reported-by: default avatarMichel Dänzer <michel@daenzer.net>
      Suggested-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      5c8c5c98
    • Christian König's avatar
      drm/radeon: fix irq ring buffer overflow handling · 8212ac73
      Christian König authored
      commit e8c214d2 upstream.
      
      We must mask out the overflow bit as well, otherwise
      the wptr will never match the rptr again and the interrupt
      handler will loop forever.
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8212ac73
    • Sven Wegener's avatar
      x86_32, entry: Store badsys error code in %eax · e22bad0c
      Sven Wegener authored
      commit 8142b215 upstream.
      
      Commit 554086d8 ("x86_32, entry: Do syscall exit work on badsys
      (CVE-2014-4508)") introduced a regression in the x86_32 syscall entry
      code, resulting in syscall() not returning proper errors for undefined
      syscalls on CPUs supporting the sysenter feature.
      
      The following code:
      
      > int result = syscall(666);
      > printf("result=%d errno=%d error=%s\n", result, errno, strerror(errno));
      
      results in:
      
      > result=666 errno=0 error=Success
      
      Obviously, the syscall return value is the called syscall number, but it
      should have been an ENOSYS error. When run under ptrace it behaves
      correctly, which makes it hard to debug in the wild:
      
      > result=-1 errno=38 error=Function not implemented
      
      The %eax register is the return value register. For debugging via ptrace
      the syscall entry code stores the complete register context on the
      stack. The badsys handlers only store the ENOSYS error code in the
      ptrace register set and do not set %eax like a regular syscall handler
      would. The old resume_userspace call chain contains code that clobbers
      %eax and it restores %eax from the ptrace registers afterwards. The same
      goes for the ptrace-enabled call chain. When ptrace is not used, the
      syscall return value is the passed-in syscall number from the untouched
      %eax register.
      
      Use %eax as the return value register in syscall_badsys and
      sysenter_badsys, like a real syscall handler does, and have the caller
      push the value onto the stack for ptrace access.
      Signed-off-by: default avatarSven Wegener <sven.wegener@stealer.net>
      Link: http://lkml.kernel.org/r/alpine.LNX.2.11.1407221022380.31021@titan.int.lan.stealer.netReviewed-and-tested-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e22bad0c
    • Vasily Averin's avatar
      fs: umount on symlink leaks mnt count · 37b0ade4
      Vasily Averin authored
      commit 295dc39d upstream.
      
      Currently umount on symlink blocks following umount:
      
      /vz is separate mount
      
      # ls /vz/ -al | grep test
      drwxr-xr-x.  2 root root       4096 Jul 19 01:14 testdir
      lrwxrwxrwx.  1 root root         11 Jul 19 01:16 testlink -> /vz/testdir
      # umount -l /vz/testlink
      umount: /vz/testlink: not mounted (expected)
      
      # lsof /vz
      # umount /vz
      umount: /vz: device is busy. (unexpected)
      
      In this case mountpoint_last() gets an extra refcount on path->mnt
      Signed-off-by: default avatarVasily Averin <vvs@openvz.org>
      Acked-by: default avatarIan Kent <raven@themaw.net>
      Acked-by: default avatarJeff Layton <jlayton@primarydata.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      37b0ade4
    • Guenter Roeck's avatar
      hwmon: (smsc47m192) Fix temperature limit and vrm write operations · dd816b45
      Guenter Roeck authored
      commit 043572d5 upstream.
      
      Temperature limit clamps are applied after converting the temperature
      from milli-degrees C to degrees C, so either the clamp limit needs
      to be specified in degrees C, not milli-degrees C, or clamping must
      happen before converting to degrees C. Use the latter method to avoid
      overflows.
      
      vrm is an u8, so the written value needs to be limited to [0, 255].
      
      Cc: Axel Lin <axel.lin@ingics.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      dd816b45
    • John David Anglin's avatar
      parisc: Remove SA_RESTORER define · ad8f50f8
      John David Anglin authored
      commit 20dbea49 upstream.
      
      The sa_restorer field in struct sigaction is obsolete and no longer in
      the parisc implementation.  However, the core code assumes the field is
      present if SA_RESTORER is defined. So, the define needs to be removed.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ad8f50f8
    • Silesh C V's avatar
      coredump: fix the setting of PF_DUMPCORE · 1e6be3dd
      Silesh C V authored
      commit aed8adb7 upstream.
      
      Commit 079148b9 ("coredump: factor out the setting of PF_DUMPCORE")
      cleaned up the setting of PF_DUMPCORE by removing it from all the
      linux_binfmt->core_dump() and moving it to zap_threads().But this ended
      up clearing all the previously set flags.  This causes issues during
      core generation when tsk->flags is checked again (eg.  for PF_USED_MATH
      to dump floating point registers).  Fix this.
      Signed-off-by: default avatarSilesh C V <svellattu@mvista.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Mandeep Singh Baines <msb@chromium.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1e6be3dd
    • Dmitry Torokhov's avatar
      Input: fix defuzzing logic · b1e86fbd
      Dmitry Torokhov authored
      commit 50c5d36d upstream.
      
      We attempt to remove noise from coordinates reported by devices in
      input_handle_abs_event(), unfortunately, unless we were dropping the
      event altogether, we were ignoring the adjusted value and were passing
      on the original value instead.
      Reviewed-by: default avatarAndrew de los Reyes <adlr@chromium.org>
      Reviewed-by: default avatarBenson Leung <bleung@chromium.org>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: default avatarHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b1e86fbd
    • Mikulas Patocka's avatar
      slab_common: fix the check for duplicate slab names · 47eaa7f5
      Mikulas Patocka authored
      commit 69461747 upstream.
      
      The patch 3e374919 is supposed to fix the
      problem where kmem_cache_create incorrectly reports duplicate cache name
      and fails. The problem is described in the header of that patch.
      
      However, the patch doesn't really fix the problem because of these
      reasons:
      
      * the logic to test for debugging is reversed. It was intended to perform
        the check only if slub debugging is enabled (which implies that caches
        with the same parameters are not merged). Therefore, there should be
        #if !defined(CONFIG_SLUB) || defined(CONFIG_SLUB_DEBUG_ON)
        The current code has the condition reversed and performs the test if
        debugging is disabled.
      
      * slub debugging may be enabled or disabled based on kernel command line,
        CONFIG_SLUB_DEBUG_ON is just the default settings. Therefore the test
        based on definition of CONFIG_SLUB_DEBUG_ON is unreliable.
      
      This patch fixes the problem by removing the test
      "!defined(CONFIG_SLUB_DEBUG_ON)". Therefore, duplicate names are never
      checked if the SLUB allocator is used.
      
      Note to stable kernel maintainers: when backporint this patch, please
      backport also the patch 3e374919.
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarPekka Enberg <penberg@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      47eaa7f5
    • Tony Luck's avatar
      tracing: Fix wraparound problems in "uptime" trace clock · 6ba0e343
      Tony Luck authored
      commit 58d4e21e upstream.
      
      The "uptime" trace clock added in:
      
          commit 8aacf017
          tracing: Add "uptime" trace clock that uses jiffies
      
      has wraparound problems when the system has been up more
      than 1 hour 11 minutes and 34 seconds. It converts jiffies
      to nanoseconds using:
              (u64)jiffies_to_usecs(jiffy) * 1000ULL
      but since jiffies_to_usecs() only returns a 32-bit value, it
      truncates at 2^32 microseconds.  An additional problem on 32-bit
      systems is that the argument is "unsigned long", so fixing the
      return value only helps until 2^32 jiffies (49.7 days on a HZ=1000
      system).
      
      Avoid these problems by using jiffies_64 as our basis, and
      not converting to nanoseconds (we do convert to clock_t because
      user facing API must not be dependent on internal kernel
      HZ values).
      
      Link: http://lkml.kernel.org/p/99d63c5bfe9b320a3b428d773825a37095bf6a51.1405708254.git.tony.luck@intel.com
      
      Fixes: 8aacf017 "tracing: Add "uptime" trace clock that uses jiffies"
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6ba0e343
    • Tejun Heo's avatar
      blkcg: don't call into policy draining if root_blkg is already gone · 1f74870f
      Tejun Heo authored
      commit 0b462c89 upstream.
      
      While a queue is being destroyed, all the blkgs are destroyed and its
      ->root_blkg pointer is set to NULL.  If someone else starts to drain
      while the queue is in this state, the following oops happens.
      
        NULL pointer dereference at 0000000000000028
        IP: [<ffffffff8144e944>] blk_throtl_drain+0x84/0x230
        PGD e4a1067 PUD b773067 PMD 0
        Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
        Modules linked in: cfq_iosched(-) [last unloaded: cfq_iosched]
        CPU: 1 PID: 537 Comm: bash Not tainted 3.16.0-rc3-work+ #2
        Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
        task: ffff88000e222250 ti: ffff88000efd4000 task.ti: ffff88000efd4000
        RIP: 0010:[<ffffffff8144e944>]  [<ffffffff8144e944>] blk_throtl_drain+0x84/0x230
        RSP: 0018:ffff88000efd7bf0  EFLAGS: 00010046
        RAX: 0000000000000000 RBX: ffff880015091450 RCX: 0000000000000001
        RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
        RBP: ffff88000efd7c10 R08: 0000000000000000 R09: 0000000000000001
        R10: ffff88000e222250 R11: 0000000000000000 R12: ffff880015091450
        R13: ffff880015092e00 R14: ffff880015091d70 R15: ffff88001508fc28
        FS:  00007f1332650740(0000) GS:ffff88001fa80000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000000028 CR3: 0000000009446000 CR4: 00000000000006e0
        Stack:
         ffffffff8144e8f6 ffff880015091450 0000000000000000 ffff880015091d80
         ffff88000efd7c28 ffffffff8144ae2f ffff880015091450 ffff88000efd7c58
         ffffffff81427641 ffff880015091450 ffffffff82401f00 ffff880015091450
        Call Trace:
         [<ffffffff8144ae2f>] blkcg_drain_queue+0x1f/0x60
         [<ffffffff81427641>] __blk_drain_queue+0x71/0x180
         [<ffffffff81429b3e>] blk_queue_bypass_start+0x6e/0xb0
         [<ffffffff814498b8>] blkcg_deactivate_policy+0x38/0x120
         [<ffffffff8144ec44>] blk_throtl_exit+0x34/0x50
         [<ffffffff8144aea5>] blkcg_exit_queue+0x35/0x40
         [<ffffffff8142d476>] blk_release_queue+0x26/0xd0
         [<ffffffff81454968>] kobject_cleanup+0x38/0x70
         [<ffffffff81454848>] kobject_put+0x28/0x60
         [<ffffffff81427505>] blk_put_queue+0x15/0x20
         [<ffffffff817d07bb>] scsi_device_dev_release_usercontext+0x16b/0x1c0
         [<ffffffff810bc339>] execute_in_process_context+0x89/0xa0
         [<ffffffff817d064c>] scsi_device_dev_release+0x1c/0x20
         [<ffffffff817930e2>] device_release+0x32/0xa0
         [<ffffffff81454968>] kobject_cleanup+0x38/0x70
         [<ffffffff81454848>] kobject_put+0x28/0x60
         [<ffffffff817934d7>] put_device+0x17/0x20
         [<ffffffff817d11b9>] __scsi_remove_device+0xa9/0xe0
         [<ffffffff817d121b>] scsi_remove_device+0x2b/0x40
         [<ffffffff817d1257>] sdev_store_delete+0x27/0x30
         [<ffffffff81792ca8>] dev_attr_store+0x18/0x30
         [<ffffffff8126f75e>] sysfs_kf_write+0x3e/0x50
         [<ffffffff8126ea87>] kernfs_fop_write+0xe7/0x170
         [<ffffffff811f5e9f>] vfs_write+0xaf/0x1d0
         [<ffffffff811f69bd>] SyS_write+0x4d/0xc0
         [<ffffffff81d24692>] system_call_fastpath+0x16/0x1b
      
      776687bc ("block, blk-mq: draining can't be skipped even if
      bypass_depth was non-zero") made it easier to trigger this bug by
      making blk_queue_bypass_start() drain even when it loses the first
      bypass test to blk_cleanup_queue(); however, the bug has always been
      there even before the commit as blk_queue_bypass_start() could race
      against queue destruction, win the initial bypass test but perform the
      actual draining after blk_cleanup_queue() already destroyed all blkgs.
      
      Fix it by skippping calling into policy draining if all the blkgs are
      already gone.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarShirish Pargaonkar <spargaonkar@suse.com>
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Reported-by: default avatarJet Chen <jet.chen@intel.com>
      Tested-by: default avatarShirish Pargaonkar <spargaonkar@suse.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1f74870f
    • Romain Degez's avatar
      ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode) · d62d41a0
      Romain Degez authored
      commit b32bfc06 upstream.
      
      Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by
      registering the board in the ahci_pci_tbl[].
      
      Note: this HBA also provide a hardware RAID mode when activated in
      BIOS but specific drivers from the manufacturer are required in this
      case.
      Signed-off-by: default avatarRomain Degez <romain.degez@gmail.com>
      Tested-by: default avatarRomain Degez <romain.degez@gmail.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d62d41a0
    • Tejun Heo's avatar
      libata: introduce ata_host->n_tags to avoid oops on SAS controllers · 44c038a9
      Tejun Heo authored
      commit 1a112d10 upstream.
      
      1871ee13 ("libata: support the ata host which implements a queue
      depth less than 32") directly used ata_port->scsi_host->can_queue from
      ata_qc_new() to determine the number of tags supported by the host;
      unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
      leading to the following oops.
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
       IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
       PGD 0
       Oops: 0002 [#1] SMP
       Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
       CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
       Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
       task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
       RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
       RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
       RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
       RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
       RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
       R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
       R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
       FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
       Stack:
        ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
        ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
        ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
       Call Trace:
        [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
        [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
        [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300
        [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
        [<ffffffff81317613>] __blk_run_queue+0x33/0x40
        [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
        [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
        [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
        [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
        [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
        [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
        [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
        [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
        [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
        [<ffffffff811e3734>] vfs_read+0x94/0x170
        [<ffffffff811e43c6>] SyS_read+0x46/0xb0
        [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
        [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
       Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00
      
      Fix it by introducing ata_host->n_tags which is initialized to
      ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
      scsi_host_template->can_queue in ata_host_register() for !SAS ones.
      As SAS hosts are never registered, this will give them the same
      ATA_MAX_QUEUE - 1 as before.  Note that we can't use
      scsi_host->can_queue directly for SAS hosts anyway as they can go
      higher than the libata maximum.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarMike Qiu <qiudayu@linux.vnet.ibm.com>
      Reported-by: default avatarJesse Brandeburg <jesse.brandeburg@gmail.com>
      Reported-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Reported-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Tested-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Fixes: 1871ee13 ("libata: support the ata host which implements a queue depth less than 32")
      Cc: Kevin Hao <haokexin@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      44c038a9
    • Kevin Hao's avatar
      libata: support the ata host which implements a queue depth less than 32 · 7e8fe962
      Kevin Hao authored
      commit 1871ee13 upstream.
      
      The sata on fsl mpc8315e is broken after the commit 8a4aeec8
      ("libata/ahci: accommodate tag ordered controllers"). The reason is
      that the ata controller on this SoC only implement a queue depth of
      16. When issuing the commands in tag order, all the commands in tag
      16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
      malfunction. It makes no senses to use a 32 queue in software while
      the hardware has less queue depth. So consider the queue depth
      implemented by the hardware when requesting a command tag.
      
      Fixes: 8a4aeec8 ("libata/ahci: accommodate tag ordered controllers")
      Signed-off-by: default avatarKevin Hao <haokexin@gmail.com>
      Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      7e8fe962
    • Christoph Hellwig's avatar
      block: don't assume last put of shared tags is for the host · b786221f
      Christoph Hellwig authored
      commit d45b3279 upstream.
      
      There is no inherent reason why the last put of a tag structure must be
      the one for the Scsi_Host, as device model objects can be held for
      arbitrary periods.  Merge blk_free_tags and __blk_free_tags into a single
      funtion that just release a references and get rid of the BUG() when the
      host reference wasn't the last.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b786221f
    • Mikulas Patocka's avatar
      block: provide compat ioctl for BLKZEROOUT · be8e9363
      Mikulas Patocka authored
      commit 3b3a1814 upstream.
      
      This patch provides the compat BLKZEROOUT ioctl. The argument is a pointer
      to two uint64_t values, so there is no need to translate it.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Acked-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      be8e9363
    • Antti Palosaari's avatar
      media: tda10071: force modulation to QPSK on DVB-S · aa0bb3b5
      Antti Palosaari authored
      commit db4175ae upstream.
      
      Only supported modulation for DVB-S is QPSK. Modulation parameter
      contains invalid value for DVB-S on some cases, which leads driver
      refusing tuning attempt. Due to that, hard code modulation to QPSK
      in case of DVB-S.
      Signed-off-by: default avatarAntti Palosaari <crope@iki.fi>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      aa0bb3b5
    • Hans Verkuil's avatar
      media: hdpvr: fix two audio bugs · 21e636e7
      Hans Verkuil authored
      commit 3445857b upstream.
      
      When the audio encoding is changed the driver calls hdpvr_set_audio
      with the current opt->audio_input value. However, that should have
      been opt->audio_input + 1. So changing the audio encoding inadvertently
      changes the input as well. This bug has always been there.
      
      The second bug was introduced in kernel 3.10 and that broke the
      default_audio_input module option handling: the audio encoding was
      never switched to AC3 if default_audio_input was set to 2 (SPDIF input).
      
      In addition, since starting with 3.10 the audio encoding is always set
      at the start the first bug now always happens when the driver is loaded.
      In the past this bug would only surface if the user would change the
      audio encoding after the driver was loaded.
      
      Also fixes a small trivial typo (bufffer -> buffer).
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Reported-by: default avatarScott Doty <scott@corp.sonic.net>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      21e636e7
    • Rickard Strandqvist's avatar
  2. 29 Jul, 2014 21 commits