1. 17 Nov, 2014 12 commits
    • Jens Axboe's avatar
      blk-mq: fix potential hang if rolling wakeup depth is too high · 36df0107
      Jens Axboe authored
      commit abab13b5 upstream.
      
      We currently divide the queue depth by 4 as our batch wakeup
      count, but we split the wakeups over BT_WAIT_QUEUES number of
      wait queues. This defaults to 8. If the product of the resulting
      batch wake count and BT_WAIT_QUEUES is higher than the device
      queue depth, we can get into a situation where a task goes to
      sleep waiting for a request, but never gets woken up.
      Reported-by: default avatarBart Van Assche <bvanassche@acm.org>
      Fixes: 4bb659b1Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      36df0107
    • Vitaly Kuznetsov's avatar
      xen/blkback: unmap all persistent grants when frontend gets disconnected · c4221e3f
      Vitaly Kuznetsov authored
      commit 12ea7296 upstream.
      
      blkback does not unmap persistent grants when frontend goes to Closed
      state (e.g. when blkfront module is being removed). This leads to the
      following in guest's dmesg:
      
      [  343.243825] xen:grant_table: WARNING: g.e. 0x445 still in use!
      [  343.243825] xen:grant_table: WARNING: g.e. 0x42a still in use!
      ...
      
      When load module -> use device -> unload module sequence is performed multiple times
      it is possible to hit BUG() condition in blkfront module:
      
      [  343.243825] kernel BUG at drivers/block/xen-blkfront.c:954!
      [  343.243825] invalid opcode: 0000 [#1] SMP
      [  343.243825] Modules linked in: xen_blkfront(-) ata_generic pata_acpi [last unloaded: xen_blkfront]
      ...
      [  343.243825] Call Trace:
      [  343.243825]  [<ffffffff814111ef>] ? unregister_xenbus_watch+0x16f/0x1e0
      [  343.243825]  [<ffffffffa0016fbf>] blkfront_remove+0x3f/0x140 [xen_blkfront]
      ...
      [  343.243825] RIP  [<ffffffffa0016aae>] blkif_free+0x34e/0x360 [xen_blkfront]
      [  343.243825]  RSP <ffff88001eb8fdc0>
      
      We don't need to keep these grants if we're disconnecting as frontend might already
      forgot about them. Solve the issue by moving xen_blkbk_free_caches() call from
      xen_blkif_free() to xen_blkif_disconnect().
      
      Now we can see the following:
      [  928.590893] xen:grant_table: WARNING: g.e. 0x587 still in use!
      [  928.591861] xen:grant_table: WARNING: g.e. 0x372 still in use!
      ...
      [  929.592146] xen:grant_table: freeing g.e. 0x587
      [  929.597174] xen:grant_table: freeing g.e. 0x372
      ...
      
      Backend does not keep persistent grants any more, reconnect works fine.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c4221e3f
    • Michael S. Tsirkin's avatar
      virtio_pci: fix virtio spec compliance on restore · 9dd5d30b
      Michael S. Tsirkin authored
      commit 6fbc198c upstream.
      
      On restore, virtio pci does the following:
      + set features
      + init vqs etc - device can be used at this point!
      + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits
      
      This is in violation of the virtio spec, which
      requires the following order:
      - ACKNOWLEDGE
      - DRIVER
      - init vqs
      - DRIVER_OK
      
      This behaviour will break with hypervisors that assume spec compliant
      behaviour.  It seems like a good idea to have this patch applied to
      stable branches to reduce the support butden for the hypervisors.
      
      Cc: Amit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9dd5d30b
    • Krzysztof Kozlowski's avatar
      power: charger-manager: Fix NULL pointer exception with missing cm-fuel-gauge · d0e18713
      Krzysztof Kozlowski authored
      commit 661a8886 upstream.
      
      NULL pointer exception happens during charger-manager probe if
      'cm-fuel-gauge' property is not present.
      
      [    2.448536] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [    2.456572] pgd = c0004000
      [    2.459217] [00000000] *pgd=00000000
      [    2.462759] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      [    2.468047] Modules linked in:
      [    2.471089] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc6-00251-ge44cf96cd525-dirty #969
      [    2.479765] task: ea890000 ti: ea87a000 task.ti: ea87a000
      [    2.485161] PC is at strcmp+0x4/0x30
      [    2.488719] LR is at power_supply_match_device_by_name+0x10/0x1c
      [    2.494695] pc : [<c01f4220>]    lr : [<c030fe38>]    psr: a0000113
      [    2.494695] sp : ea87bde0  ip : 00000000  fp : eaa97010
      [    2.506150] r10: 00000004  r9 : ea97269c  r8 : ea3bbfd0
      [    2.511360] r7 : eaa97000  r6 : c030fe28  r5 : 00000000  r4 : ea3b0000
      [    2.517869] r3 : 0000006d  r2 : 00000000  r1 : 00000000  r0 : c057c195
      [    2.524381] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [    2.531671] Control: 10c5387d  Table: 4000404a  DAC: 00000015
      [    2.537399] Process swapper/0 (pid: 1, stack limit = 0xea87a240)
      [    2.543388] Stack: (0xea87bde0 to 0xea87c000)
      [    2.547733] bde0: ea3b0210 c026b1c8 eaa97010 eaa97000 eaa97010 eabb60a8 ea3b0210 00000000
      [    2.555891] be00: 00000008 ea2db210 ea1a3410 c030fee0 ea3bbf90 c03138fc c068969c c013526c
      [    2.564050] be20: eaa040c0 00000000 c068969c 00000000 eaa040c0 ea2da300 00000002 00000000
      [    2.572208] be40: 00000001 ea2da3c0 00000000 00000001 00000000 eaa97010 c068969c 00000000
      [    2.580367] be60: 00000000 c068969c 00000000 00000002 00000000 c026b71c c026b6f0 eaa97010
      [    2.588527] be80: c0e82530 c026a330 00000000 eaa97010 c068969c eaa97044 00000000 c061df50
      [    2.596686] bea0: ea87a000 c026a4dc 00000000 c068969c c026a448 c0268b5c ea8054a8 eaa8fd50
      [    2.604845] bec0: c068969c ea2db180 c06801f8 c0269b18 c0590f68 c068969c c0656c98 c068969c
      [    2.613004] bee0: c0656c98 ea3bbe40 c06988c0 c026aaf0 00000000 c0656c98 c0656c98 c00088a4
      [    2.621163] bf00: 00000000 c0055f48 00000000 00000004 00000000 ea890000 c05dbc54 c062c178
      [    2.629323] bf20: c0603518 c005f674 00000001 ea87a000 eb7ff83b c0476440 00000091 c003d41c
      [    2.637482] bf40: c05db344 00000007 eb7ff858 00000007 c065a76c c0647d24 00000007 c062c170
      [    2.645642] bf60: c06988c0 00000091 c062c178 c0603518 00000000 c0603cc4 00000007 00000007
      [    2.653801] bf80: c0603518 c0c0c0c0 00000000 c0453948 00000000 00000000 00000000 00000000
      [    2.661959] bfa0: 00000000 c0453950 00000000 c000e728 00000000 00000000 00000000 00000000
      [    2.670118] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    2.678277] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 c0c0c0c0 c0c0c0c0
      [    2.686454] [<c01f4220>] (strcmp) from [<c030fe38>] (power_supply_match_device_by_name+0x10/0x1c)
      [    2.695303] [<c030fe38>] (power_supply_match_device_by_name) from [<c026b1c8>] (class_find_device+0x54/0xac)
      [    2.705106] [<c026b1c8>] (class_find_device) from [<c030fee0>] (power_supply_get_by_name+0x1c/0x30)
      [    2.714137] [<c030fee0>] (power_supply_get_by_name) from [<c03138fc>] (charger_manager_probe+0x3d8/0xe58)
      [    2.723683] [<c03138fc>] (charger_manager_probe) from [<c026b71c>] (platform_drv_probe+0x2c/0x5c)
      [    2.732532] [<c026b71c>] (platform_drv_probe) from [<c026a330>] (driver_probe_device+0x10c/0x224)
      [    2.741384] [<c026a330>] (driver_probe_device) from [<c026a4dc>] (__driver_attach+0x94/0x98)
      [    2.749813] [<c026a4dc>] (__driver_attach) from [<c0268b5c>] (bus_for_each_dev+0x54/0x88)
      [    2.757969] [<c0268b5c>] (bus_for_each_dev) from [<c0269b18>] (bus_add_driver+0xd4/0x1d0)
      [    2.766123] [<c0269b18>] (bus_add_driver) from [<c026aaf0>] (driver_register+0x78/0xf4)
      [    2.774110] [<c026aaf0>] (driver_register) from [<c00088a4>] (do_one_initcall+0x80/0x1bc)
      [    2.782276] [<c00088a4>] (do_one_initcall) from [<c0603cc4>] (kernel_init_freeable+0x100/0x1cc)
      [    2.790952] [<c0603cc4>] (kernel_init_freeable) from [<c0453950>] (kernel_init+0x8/0xec)
      [    2.799029] [<c0453950>] (kernel_init) from [<c000e728>] (ret_from_fork+0x14/0x2c)
      [    2.806572] Code: e12fff1e e1a03000 eafffff7 e4d03001 (e4d12001)
      [    2.812832] ---[ end trace 7f12556111b9e7ef ]---
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 856ee611 ("charger-manager: Support deivce tree in charger manager driver")
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d0e18713
    • Stephen Smalley's avatar
      selinux: fix inode security list corruption · bb62683e
      Stephen Smalley authored
      commit 923190d3 upstream.
      
      sb_finish_set_opts() can race with inode_free_security()
      when initializing inode security structures for inodes
      created prior to initial policy load or by the filesystem
      during ->mount().   This appears to have always been
      a possible race, but commit 3dc91d43 ("SELinux:  Fix possible
      NULL pointer dereference in selinux_inode_permission()")
      made it more evident by immediately reusing the unioned
      list/rcu element  of the inode security structure for call_rcu()
      upon an inode_free_security().  But the underlying issue
      was already present before that commit as a possible use-after-free
      of isec.
      
      Shivnandan Kumar reported the list corruption and proposed
      a patch to split the list and rcu elements out of the union
      as separate fields of the inode_security_struct so that setting
      the rcu element would not affect the list element.  However,
      this would merely hide the issue and not truly fix the code.
      
      This patch instead moves up the deletion of the list entry
      prior to dropping the sbsec->isec_lock initially.  Then,
      if the inode is dropped subsequently, there will be no further
      references to the isec.
      Reported-by: default avatarShivnandan Kumar <shivnandan.k@samsung.com>
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bb62683e
    • Chris Ball's avatar
      mfd: rtsx_pcr: Fix MSI enable error handling · 2192ea7d
      Chris Ball authored
      commit 51529705 upstream.
      
      pci_enable_msi() can return failure with both positive and negative
      integers -- it returns 0 for success -- but is only tested here for
      "if (ret < 0)".  This causes us to try to use MSI on the RTS5249 SD
      reader in the Dell XPS 11 when enabling MSI failed, causing:
      
      [    1.737110] rtsx_pci: probe of 0000:05:00.0 failed with error -110
      Reported-by: default avatarD. Jared Dominguez <Jared_Dominguez@Dell.com>
      Tested-by: default avatarD. Jared Dominguez <Jared_Dominguez@Dell.com>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2192ea7d
    • Sebastian Andrzej Siewior's avatar
      mfd: ti_am335x_tscadc: Fix TSC resume · c5a2357f
      Sebastian Andrzej Siewior authored
      commit 6a71f38d upstream.
      
      In the resume path, the ADC invokes am335x_tsc_se_set_cache() with 0 as
      the steps argument if continous mode is not in use. This in turn disables
      all steps and so the TSC is not working until one ADC sampling is
      performed.
      
      This patch fixes it by writing the current cached mask instead of the
      passed steps.
      
      Fixes: 7ca6740c ("mfd: input: iio: ti_amm335x: Rework TSC/ADCA
      synchronization")
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c5a2357f
    • Vignesh R's avatar
      mfd: ti_am335x_tscadc: Fix TSC operation after ADC continouous mode · 4cc4c1f4
      Vignesh R authored
      commit 6ac734d2 upstream.
      
      After enabling and disabling ADC continuous mode via sysfs, ts_print_raw
      fails to return any data. This is because when ADC is configured for
      continuous mode, it disables touch screen steps.These steps are not
      re-enabled when ADC continuous mode is disabled. Therefore existing values
      of REG_SE needs to be cached before enabling continuous mode and
      disabling touch screen steps and enabling ADC steps. The cached value
      are to be restored to REG_SE once ADC is disabled.
      
      Fixes: 7ca6740c ("mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization")
      Signed-off-by: default avatarVignesh R <vigneshr@ti.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4cc4c1f4
    • Martin Schwidefsky's avatar
      s390/topology: call set_sched_topology early · 8d765b88
      Martin Schwidefsky authored
      commit 48e9a6c1 upstream.
      
      The call to topology_init is too late for the set_sched_topology call.
      The initial scheduling domain structure has already been established
      with default topology array. Use the smp_cpus_done() call to get the
      s390 specific topology array registered early enough.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8d765b88
    • Thorsten Knabe's avatar
      um: ubd: Fix for processes stuck in D state forever · fd6baa91
      Thorsten Knabe authored
      commit 2a236122 upstream.
      
      Starting with Linux 3.12 processes get stuck in D state forever in
      UserModeLinux under sync heavy workloads. This bug was introduced by
      commit 805f11a0 (um: ubd: Add REQ_FLUSH suppport).
      Fix bug by adding a check if FLUSH request was successfully submitted to
      the I/O thread and keeping the FLUSH request on the request queue on
      submission failures.
      
      Fixes: 805f11a0 (um: ubd: Add REQ_FLUSH suppport)
      Signed-off-by: default avatarThorsten Knabe <linux@thorsten-knabe.de>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fd6baa91
    • Kirill Tkhai's avatar
      sched: Use dl_bw_of() under RCU read lock · 49bef5ac
      Kirill Tkhai authored
      commit 66339c31 upstream.
      
      dl_bw_of() dereferences rq->rd which has to have RCU read lock held.
      Probability of use-after-free isn't zero here.
      
      Also add lockdep assert into dl_bw_cpus().
      Signed-off-by: default avatarKirill Tkhai <ktkhai@parallels.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20140922183624.11015.71558.stgit@localhostSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      49bef5ac
    • Ilya Dryomov's avatar
      libceph: ceph-msgr workqueue needs a resque worker · 427ee2fa
      Ilya Dryomov authored
      commit f9865f06 upstream.
      
      Commit f363e45f ("net/ceph: make ceph_msgr_wq non-reentrant")
      effectively removed WQ_MEM_RECLAIM flag from ceph_msgr_wq.  This is
      wrong - libceph is very much a memory reclaim path, so restore it.
      Signed-off-by: default avatarIlya Dryomov <idryomov@redhat.com>
      Tested-by: default avatarMicha Krause <micha@krausam.de>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      427ee2fa
  2. 14 Nov, 2014 28 commits
    • Al Viro's avatar
      fix misuses of f_count() in ppp and netlink · a0649e6d
      Al Viro authored
      commit 24dff96a upstream.
      
      we used to check for "nobody else could start doing anything with
      that opened file" by checking that refcount was 2 or less - one
      for descriptor table and one we'd acquired in fget() on the way to
      wherever we are.  That was race-prone (somebody else might have
      had a reference to descriptor table and do fget() just as we'd
      been checking) and it had become flat-out incorrect back when
      we switched to fget_light() on those codepaths - unlike fget(),
      it doesn't grab an extra reference unless the descriptor table
      is shared.  The same change allowed a race-free check, though -
      we are safe exactly when refcount is less than 2.
      
      It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading
      to ppp one) and 2.6.17 for sendmsg() (netlink one).  OTOH,
      netlink hadn't grown that check until 3.9 and ppp used to live
      in drivers/net, not drivers/net/ppp until 3.1.  The bug existed
      well before that, though, and the same fix used to apply in old
      location of file.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a0649e6d
    • Al Viro's avatar
      [jffs2] kill wbuf_queued/wbuf_dwork_lock · e61cf85b
      Al Viro authored
      commit 99358a1c upstream.
      
      schedule_delayed_work() happening when the work is already pending is
      a cheap no-op.  Don't bother with ->wbuf_queued logics - it's both
      broken (cancelling ->wbuf_dwork leaves it set, as spotted by Jeff Harris)
      and pointless.  It's cheaper to let schedule_delayed_work() handle that
      case.
      Reported-by: default avatarJeff Harris <jefftharris@gmail.com>
      Tested-by: default avatarJeff Harris <jefftharris@gmail.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e61cf85b
    • Al Viro's avatar
      missing data dependency barrier in prepend_name() · 77f1b897
      Al Viro authored
      commit 6d13f694 upstream.
      
      AFAICS, prepend_name() is broken on SMP alpha.  Disclaimer: I don't have
      SMP alpha boxen to reproduce it on.  However, it really looks like the race
      is real.
      
      CPU1: d_path() on /mnt/ramfs/<255-character>/foo
      CPU2: mv /mnt/ramfs/<255-character> /mnt/ramfs/<63-character>
      
      CPU2 does d_alloc(), which allocates an external name, stores the name there
      including terminating NUL, does smp_wmb() and stores its address in
      dentry->d_name.name.  It proceeds to d_add(dentry, NULL) and d_move()
      old dentry over to that.  ->d_name.name value ends up in that dentry.
      
      In the meanwhile, CPU1 gets to prepend_name() for that dentry.  It fetches
      ->d_name.name and ->d_name.len; the former ends up pointing to new name
      (64-byte kmalloc'ed array), the latter - 255 (length of the old name).
      Nothing to force the ordering there, and normally that would be OK, since we'd
      run into the terminating NUL and stop.  Except that it's alpha, and we'd need
      a data dependency barrier to guarantee that we see that store of NUL
      __d_alloc() has done.  In a similar situation dentry_cmp() would survive; it
      does explicit smp_read_barrier_depends() after fetching ->d_name.name.
      prepend_name() doesn't and it risks walking past the end of kmalloc'ed object
      and possibly oops due to taking a page fault in kernel mode.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      77f1b897
    • Dmitry Kasatkin's avatar
      evm: properly handle INTEGRITY_NOXATTRS EVM status · 742b40ef
      Dmitry Kasatkin authored
      commit 3dcbad52 upstream.
      
      Unless an LSM labels a file during d_instantiate(), newly created
      files are not labeled with an initial security.evm xattr, until
      the file closes.  EVM, before allowing a protected, security xattr
      to be written, verifies the existing 'security.evm' value is good.
      For newly created files without a security.evm label, this
      verification prevents writing any protected, security xattrs,
      until the file closes.
      
      Following is the example when this happens:
      fd = open("foo", O_CREAT | O_WRONLY, 0644);
      setxattr("foo", "security.SMACK64", value, sizeof(value), 0);
      close(fd);
      
      While INTEGRITY_NOXATTRS status is handled in other places, such
      as evm_inode_setattr(), it does not handle it in all cases in
      evm_protect_xattr().  By limiting the use of INTEGRITY_NOXATTRS to
      newly created files, we can now allow setting "protected" xattrs.
      
      Changelog:
      - limit the use of INTEGRITY_NOXATTRS to IMA identified new files
      Signed-off-by: default avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      742b40ef
    • Peter Zijlstra's avatar
      perf: Fix unclone_ctx() vs. locking · a69e3e3e
      Peter Zijlstra authored
      commit 211de6eb upstream.
      
      The idiot who did 4a1c0f26 ("perf: Fix lockdep warning on process exit")
      forgot to pay attention and fix all similar cases. Do so now.
      
      In particular, unclone_ctx() must be called while holding ctx->lock,
      therefore all such sites are broken for the same reason. Pull the
      put_ctx() call out from under ctx->lock.
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Probably-also-reported-by: default avatarVince Weaver <vincent.weaver@maine.edu>
      Fixes: 4a1c0f26 ("perf: Fix lockdep warning on process exit")
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Cong Wang <cwang@twopensource.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/20140930172308.GI4241@worktop.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a69e3e3e
    • Oleg Nesterov's avatar
      x86, fpu: shift drop_init_fpu() from save_xstate_sig() to handle_signal() · 2abb5534
      Oleg Nesterov authored
      commit 66463db4 upstream.
      
      save_xstate_sig()->drop_init_fpu() doesn't look right. setup_rt_frame()
      can fail after that, in this case the next setup_rt_frame() triggered
      by SIGSEGV won't save fpu simply because the old state was lost. This
      obviously mean that fpu won't be restored after sys_rt_sigreturn() from
      SIGSEGV handler.
      
      Shift drop_init_fpu() into !failed branch in handle_signal().
      
      Test-case (needs -O2):
      
      	#include <stdio.h>
      	#include <signal.h>
      	#include <unistd.h>
      	#include <sys/syscall.h>
      	#include <sys/mman.h>
      	#include <pthread.h>
      	#include <assert.h>
      
      	volatile double D;
      
      	void test(double d)
      	{
      		int pid = getpid();
      
      		for (D = d; D == d; ) {
      			/* sys_tkill(pid, SIGHUP); asm to avoid save/reload
      			 * fp regs around "C" call */
      			asm ("" : : "a"(200), "D"(pid), "S"(1));
      			asm ("syscall" : : : "ax");
      		}
      
      		printf("ERR!!\n");
      	}
      
      	void sigh(int sig)
      	{
      	}
      
      	char altstack[4096 * 10] __attribute__((aligned(4096)));
      
      	void *tfunc(void *arg)
      	{
      		for (;;) {
      			mprotect(altstack, sizeof(altstack), PROT_READ);
      			mprotect(altstack, sizeof(altstack), PROT_READ|PROT_WRITE);
      		}
      	}
      
      	int main(void)
      	{
      		stack_t st = {
      			.ss_sp = altstack,
      			.ss_size = sizeof(altstack),
      			.ss_flags = SS_ONSTACK,
      		};
      
      		struct sigaction sa = {
      			.sa_handler = sigh,
      		};
      
      		pthread_t pt;
      
      		sigaction(SIGSEGV, &sa, NULL);
      		sigaltstack(&st, NULL);
      		sa.sa_flags = SA_ONSTACK;
      		sigaction(SIGHUP, &sa, NULL);
      
      		pthread_create(&pt, NULL, tfunc, NULL);
      
      		test(123.456);
      		return 0;
      	}
      Reported-by: default avatarBean Anderson <bean@azulsystems.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Link: http://lkml.kernel.org/r/20140902175713.GA21646@redhat.comSigned-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2abb5534
    • Oleg Nesterov's avatar
      x86, fpu: __restore_xstate_sig()->math_state_restore() needs preempt_disable() · dd073d97
      Oleg Nesterov authored
      commit df24fb85 upstream.
      
      Add preempt_disable() + preempt_enable() around math_state_restore() in
      __restore_xstate_sig(). Otherwise __switch_to() after __thread_fpu_begin()
      can overwrite fpu->state we are going to restore.
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Link: http://lkml.kernel.org/r/20140902175717.GA21649@redhat.comReviewed-by: default avatarSuresh Siddha <sbsiddha@gmail.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dd073d97
    • Ben Hutchings's avatar
      x86: Reject x32 executables if x32 ABI not supported · 62c3b5a2
      Ben Hutchings authored
      commit 0e6d3112 upstream.
      
      It is currently possible to execve() an x32 executable on an x86_64
      kernel that has only ia32 compat enabled.  However all its syscalls
      will fail, even _exit().  This usually causes it to segfault.
      
      Change the ELF compat architecture check so that x32 executables are
      rejected if we don't support the x32 ABI.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Link: http://lkml.kernel.org/r/1410120305.6822.9.camel@decadent.org.ukSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      62c3b5a2
    • Artem Bityutskiy's avatar
      UBIFS: fix free log space calculation · bd5a63d5
      Artem Bityutskiy authored
      commit ba29e721 upstream.
      
      Hu (hujianyang <hujianyang@huawei.com>) discovered an issue in the
      'empty_log_bytes()' function, which calculates how many bytes are left in the
      log:
      
      "
      If 'c->lhead_lnum + 1 == c->ltail_lnum' and 'c->lhead_offs == c->leb_size', 'h'
      would equalent to 't' and 'empty_log_bytes()' would return 'c->log_bytes'
      instead of 0.
      "
      
      At this point it is not clear what would be the consequences of this, and
      whether this may lead to any problems, but this patch addresses the issue just
      in case.
      Tested-by: default avatarhujianyang <hujianyang@huawei.com>
      Reported-by: default avatarhujianyang <hujianyang@huawei.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bd5a63d5
    • Artem Bityutskiy's avatar
      UBIFS: fix a race condition · ba82b50b
      Artem Bityutskiy authored
      commit 052c2807 upstream.
      
      Hu (hujianyang@huawei.com) discovered a race condition which may lead to a
      situation when UBIFS is unable to mount the file-system after an unclean
      reboot. The problem is theoretical, though.
      
      In UBIFS, we have the log, which basically a set of LEBs in a certain area. The
      log has the tail and the head.
      
      Every time user writes data to the file-system, the UBIFS journal grows, and
      the log grows as well, because we append new reference nodes to the head of the
      log. So the head moves forward all the time, while the log tail stays at the
      same position.
      
      At any time, the UBIFS master node points to the tail of the log. When we mount
      the file-system, we scan the log, and we always start from its tail, because
      this is where the master node points to. The only occasion when the tail of the
      log changes is the commit operation.
      
      The commit operation has 2 phases - "commit start" and "commit end". The former
      is relatively short, and does not involve much I/O. During this phase we mostly
      just build various in-memory lists of the things which have to be written to
      the flash media during "commit end" phase.
      
      During the commit start phase, what we do is we "clean" the log. Indeed, the
      commit operation will index all the data in the journal, so the entire journal
      "disappears", and therefore the data in the log become unneeded. So we just
      move the head of the log to the next LEB, and write the CS node there. This LEB
      will be the tail of the new log when the commit operation finishes.
      
      When the "commit start" phase finishes, users may write more data to the
      file-system, in parallel with the ongoing "commit end" operation. At this point
      the log tail was not changed yet, it is the same as it had been before we
      started the commit. The log head keeps moving forward, though.
      
      The commit operation now needs to write the new master node, and the new master
      node should point to the new log tail. After this the LEBs between the old log
      tail and the new log tail can be unmapped and re-used again.
      
      And here is the possible problem. We do 2 operations: (a) We first update the
      log tail position in memory (see 'ubifs_log_end_commit()'). (b) And then we
      write the master node (see the big lock of code in 'do_commit()').
      
      But nothing prevents the log head from moving forward between (a) and (b), and
      the log head may "wrap" now to the old log tail. And when the "wrap" happens,
      the contends of the log tail gets erased. Now a power cut happens and we are in
      trouble. We end up with the old master node pointing to the old tail, which was
      erased. And replay fails because it expects the master node to point to the
      correct log tail at all times.
      
      This patch merges the abovementioned (a) and (b) operations by moving the master
      node change code to the 'ubifs_log_end_commit()' function, so that it runs with
      the log mutex locked, which will prevent the log from being changed benween
      operations (a) and (b).
      Reported-by: default avatarhujianyang <hujianyang@huawei.com>
      Tested-by: default avatarhujianyang <hujianyang@huawei.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ba82b50b
    • Artem Bityutskiy's avatar
      UBIFS: remove mst_mutex · a342c133
      Artem Bityutskiy authored
      commit 07e19dff upstream.
      
      The 'mst_mutex' is not needed since because 'ubifs_write_master()' is only
      called on the mount path and commit path. The mount path is sequential and
      there is no parallelism, and the commit path is also serialized - there is only
      one commit going on at a time.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a342c133
    • Tetsuo Handa's avatar
      fs: Fix theoretical division by 0 in super_cache_scan(). · e64a0bc3
      Tetsuo Handa authored
      commit 475d0db7 upstream.
      
      total_objects could be 0 and is used as a denom.
      
      While total_objects is a "long", total_objects == 0 unlikely happens for
      3.12 and later kernels because 32-bit architectures would not be able to
      hold (1 << 32) objects. However, total_objects == 0 may happen for kernels
      between 3.1 and 3.11 because total_objects in prune_super() was an "int"
      and (e.g.) x86_64 architecture might be able to hold (1 << 32) objects.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e64a0bc3
    • Mikulas Patocka's avatar
      fs: make cont_expand_zero interruptible · 4595138c
      Mikulas Patocka authored
      commit c2ca0fcd upstream.
      
      This patch makes it possible to kill a process looping in
      cont_expand_zero. A process may spend a lot of time in this function, so
      it is desirable to be able to kill it.
      
      It happened to me that I wanted to copy a piece data from the disk to a
      file. By mistake, I used the "seek" parameter to dd instead of "skip". Due
      to the "seek" parameter, dd attempted to extend the file and became stuck
      doing so - the only possibility was to reset the machine or wait many
      hours until the filesystem runs out of space and cont_expand_zero fails.
      We need this patch to be able to terminate the process.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4595138c
    • Bartlomiej Zolnierkiewicz's avatar
      mmc: sdhci-s3c: fix runtime PM handling on sdhci_add_host() failure · aadefebf
      Bartlomiej Zolnierkiewicz authored
      commit 221414db upstream.
      
      Runtime Power Management handling for the sdhci_add_host() failure
      case in sdhci_s3c_probe() should match the code in sdhci_s3c_remove()
      (which uses pm_runtime_disable() call which matches the earlier
      pm_runtime_enable() one).  Fix it.
      
      This patch fixes "BUG: spinlock bad magic on CPU#0, swapper/0/1" and
      "Unbalanced pm_runtime_enable!" warnings.
      
      >From the kernel log:
      ...
      [    1.659631] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
      [    1.665096] BUG: spinlock bad magic on CPU#0, swapper/0/1
      [    1.670433]  lock: 0xea01e484, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
      [    1.677895] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-next-20140804-00008-ga59480f-dirty #707
      [    1.687037] [<c0013ae4>] (unwind_backtrace) from [<c0010d70>] (show_stack+0x10/0x14)
      [    1.694740] [<c0010d70>] (show_stack) from [<c04050c8>] (dump_stack+0x68/0xb8)
      [    1.701948] [<c04050c8>] (dump_stack) from [<c0052558>] (do_raw_spin_lock+0x15c/0x1a4)
      [    1.709848] [<c0052558>] (do_raw_spin_lock) from [<c040a630>] (_raw_spin_lock_irqsave+0x20/0x28)
      [    1.718619] [<c040a630>] (_raw_spin_lock_irqsave) from [<c030d7d0>] (sdhci_do_set_ios+0x1c/0x5cc)
      [    1.727464] [<c030d7d0>] (sdhci_do_set_ios) from [<c030ddfc>] (sdhci_runtime_resume_host+0x50/0x104)
      [    1.736574] [<c030ddfc>] (sdhci_runtime_resume_host) from [<c02462dc>] (pm_generic_runtime_resume+0x2c/0x40)
      [    1.746383] [<c02462dc>] (pm_generic_runtime_resume) from [<c0247898>] (__rpm_callback+0x34/0x70)
      [    1.755233] [<c0247898>] (__rpm_callback) from [<c02478fc>] (rpm_callback+0x28/0x88)
      [    1.762958] [<c02478fc>] (rpm_callback) from [<c02486f0>] (rpm_resume+0x384/0x4ec)
      [    1.770511] [<c02486f0>] (rpm_resume) from [<c02488b0>] (pm_runtime_forbid+0x58/0x64)
      [    1.778325] [<c02488b0>] (pm_runtime_forbid) from [<c030ea70>] (sdhci_s3c_probe+0x4a4/0x540)
      [    1.786749] [<c030ea70>] (sdhci_s3c_probe) from [<c02429cc>] (platform_drv_probe+0x2c/0x5c)
      [    1.795076] [<c02429cc>] (platform_drv_probe) from [<c02415f0>] (driver_probe_device+0x114/0x234)
      [    1.803929] [<c02415f0>] (driver_probe_device) from [<c024179c>] (__driver_attach+0x8c/0x90)
      [    1.812347] [<c024179c>] (__driver_attach) from [<c023ffb4>] (bus_for_each_dev+0x54/0x88)
      [    1.820506] [<c023ffb4>] (bus_for_each_dev) from [<c0240df8>] (bus_add_driver+0xd8/0x1cc)
      [    1.828665] [<c0240df8>] (bus_add_driver) from [<c0241db8>] (driver_register+0x78/0xf4)
      [    1.836652] [<c0241db8>] (driver_register) from [<c00088a4>] (do_one_initcall+0x80/0x1d0)
      [    1.844816] [<c00088a4>] (do_one_initcall) from [<c059ac94>] (kernel_init_freeable+0x108/0x1d4)
      [    1.853503] [<c059ac94>] (kernel_init_freeable) from [<c0401300>] (kernel_init+0x8/0xe4)
      [    1.861568] [<c0401300>] (kernel_init) from [<c000e538>] (ret_from_fork+0x14/0x3c)
      [    1.869582] platform 12530000.sdhci: Driver s3c-sdhci requests probe deferral
      ...
      [    1.997047] s3c-sdhci 12530000.sdhci: Unbalanced pm_runtime_enable!
      ...
      [    2.027235] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
      [    2.032884] platform 12530000.sdhci: Driver s3c-sdhci requests probe deferral
      ...
      
      Tested on Hardkernel's Exynos4412 based ODROID-U3 board.
      
      Fixes: 9f4e8151 ("mmc: sdhci-s3c: Enable runtime power management")
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Jaehoon Chung <jh80.chung@samsung.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Acked-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      aadefebf
    • Roger Tseng's avatar
      mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response · ecca7685
      Roger Tseng authored
      commit d1419d50 upstream.
      
      Current code erroneously fill the last byte of R2 response with an undefined
      value. In addition, the controller actually 'offloads' the last byte
      (CRC7, end bit) while receiving R2 response and thus it's impossible to get the
      actual value. This could cause mmc stack to obtain inconsistent CID from the
      same card after resume and misidentify it as a different card.
      
      Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
      
      Fixes: ff984e57 ("mmc: Add realtek pcie sdmmc host driver")
      Signed-off-by: default avatarRoger Tseng <rogerable@realtek.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ecca7685
    • Stephen Warren's avatar
      mmc: don't request CD IRQ until mmc_start_host() · 01e9cd95
      Stephen Warren authored
      commit d4d11449 upstream.
      
      As soon as the CD IRQ is requested, it can trigger, since it's an
      externally controlled event. If it does, delayed_work host->detect will
      be scheduled.
      
      Many host controller probe()s are roughly structured as:
      
      *_probe() {
          host = sdhci_pltfm_init();
          mmc_of_parse(host->mmc);
          rc = sdhci_add_host(host);
          if (rc) {
              sdhci_pltfm_free();
              return rc;
          }
      
      In 3.17, CD IRQs can are enabled quite early via *_probe() ->
      mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq().
      
      Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd()
      rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't
      call mmc_gpiod_request_cd_irq(). However, this issue still exists if
      mmc_gpio_request_cd() is called directly before mmc_start_host().
      
      sdhci_add_host() may fail part way through (e.g. due to deferred
      probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to
      unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is
      coded to assume that if sdhci_add_host() failed, then the delayed_work
      cannot (or should not) have been triggered.
      
      This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when
      kfree(host) is eventually called inside sdhci_pltfm_free():
      
      WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263 debug_print_object+0x8c/0xb4()
      ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x18
      
      The object being complained about is host->detect.
      
      There's no need to request the CD IRQ so early; mmc_start_host() already
      requests it. For most SDHCI hosts at least, the typical call path that
      does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() ->
      mmc_start_host(). Therefore, remove the call to mmc_gpiod_request_cd_irq()
      from mmc_gpio_request_cd(). This also matches mmc_gpio*d*_request_cd(),
      which already doesn't call mmc_gpiod_request_cd_irq().
      
      However, some host controller drivers call mmc_gpio_request_cd() after
      mmc_start_host() has already been called, and assume that this will also
      call mmc_gpiod_request_cd_irq(). Update those drivers to explicitly call
      mmc_gpiod_request_cd_irq() themselves. Ideally, these drivers should be
      modified to move their call to mmc_gpio_request_cd() before their call
      to mmc_add_host(). However that's too large a change for stable.
      
      This solves the problem (eliminates the kernel error message above),
      since it guarantees that the IRQ can't trigger before mmc_start_host()
      is called.
      
      The critical point here is that once sdhci_add_host() calls
      mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to
      fail. In other words, if there's a chance that mmc_start_host() may have
      been called, and CD IRQs triggered, and the delayed_work scheduled,
      sdhci_add_host() won't fail, and so cleanup is no longer via
      sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue)
      but instead must be via sdhci_remove_host(), which calls mmc_remove_host()
      -> mmc_stop_host(), which does free the IRQ and cancel the work queue.
      
      CC: Russell King <linux@arm.linux.org.uk>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexandre Courbot <acourbot@nvidia.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      01e9cd95
    • Roger Tseng's avatar
      mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response · b4919807
      Roger Tseng authored
      commit 6f67cc6f upstream.
      
      Current code erroneously fill the last byte of R2 response with an undefined
      value. In addition, the controller actually 'offloads' the last byte
      (CRC7, end bit) while receiving R2 response and thus it's impossible to get the
      actual value. This could cause mmc stack to obtain inconsistent CID from the
      same card after resume and misidentify it as a different card.
      
      Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
      
      Fixes: c7f6558d ("mmc: Add realtek USB sdmmc host driver")
      Signed-off-by: default avatarRoger Tseng <rogerable@realtek.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b4919807
    • Peter Griffin's avatar
      mmc: sdhci-pxav3: set_uhs_signaling is initialized twice differently · b55a912a
      Peter Griffin authored
      commit b3153765 upstream.
      
      .set_uhs_signaling field is currently initialised twice once to the
      arch specific callback pxav3_set_uhs_signaling, and also to the generic
      sdhci_set_uhs_signaling callback.
      
      This means that uhs is currently broken for this platform currently, as pxav3
      has some special constriants which means it can't use the generic callback.
      
      This happened in
      commit 96d7b78c ("mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function")
      commit a702c8ab ("mmc: host: split up sdhci-pxa, create sdhci-pxav3.c")'
      
      Fix this and hopefully prevent it happening in the future by ensuring named
      initialisers always follow the declaration order in the structure definition.
      Signed-off-by: default avatarPeter Griffin <peter.griffin@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b55a912a
    • Fu Zhonghui's avatar
      mmc: core: sdio: Fix unconditional wake_up_process() on sdio thread · 629e846e
      Fu Zhonghui authored
      commit dea67c4e upstream.
      
      781e989c ("mmc: sdhci: convert to new SDIO IRQ handling") and
      bf3b5ec6 ("mmc: sdio_irq: rework sdio irq handling") disabled
      the use of our own custom threaded IRQ handler, but left in an
      unconditional wake_up_process() on that handler at resume-time.
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=80151
      
      In addition, the check for MMC_CAP_SDIO_IRQ capability is added
      before enable sdio IRQ.
      Signed-off-by: default avatarJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      Signed-off-by: default avatarFu Zhonghui <zhonghui.fu@linux.intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      629e846e
    • Dmitry Lavnikevich's avatar
      ASoC: tlv320aic3x: fix PLL D configuration · 0ec70e9b
      Dmitry Lavnikevich authored
      commit 31d9f8fa upstream.
      
      Current caching implementation during regcache_sync() call bypasses
      all register writes of values that are already known as default
      (regmap reg_defaults). Same time in TLV320AIC3x codecs register 5
      (AIC3X_PLL_PROGC_REG) write should be immediately followed by register
      6 write (AIC3X_PLL_PROGD_REG) even if it was not changed. Otherwise
      both registers will not be written.
      
      This brings to issue that appears particulary in case of 44.1kHz
      playback with 19.2MHz master clock. In this case AIC3X_PLL_PROGC_REG
      is 0x6e while AIC3X_PLL_PROGD_REG is 0x0 (same as register
      default). Thus AIC3X_PLL_PROGC_REG also remains not written and we get
      wrong playback speed.
      
      In this patch snd_soc_read() is used to get cached pll values and
      snd_soc_write() (unlike regcache_sync() this function doesn't bypasses
      hardware default values) to write them to registers.
      Signed-off-by: default avatarDmitry Lavnikevich <d.lavnikevich@sam-solutions.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0ec70e9b
    • Daniel Mack's avatar
      ASoC: soc-dapm: fix use after free · bf6d3fbe
      Daniel Mack authored
      commit e5092c96 upstream.
      
      Coverity spotted the following possible use-after-free condition in
      dapm_create_or_share_mixmux_kcontrol():
      
      If kcontrol is NULL, and (wname_in_long_name && kcname_in_long_name)
      validates to true, 'name' will be set to an allocated string, and be
      freed a few lines later via the 'long_name' alias. 'name', however,
      is used by dev_err() in case snd_ctl_add() fails.
      
      Fix this by adding a jump label that frees 'long_name' at the end of
      the function.
      Signed-off-by: default avatarDaniel Mack <daniel@zonque.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bf6d3fbe
    • Ondrej Zary's avatar
      libata-sff: Fix controllers with no ctl port · 07c3adf1
      Ondrej Zary authored
      commit 6d8ca28f upstream.
      
      Currently, ata_sff_softreset is skipped for controllers with no ctl port.
      But that also skips ata_sff_dev_classify required for device detection.
      This means that libata is currently broken on controllers with no ctl port.
      
      No device connected:
      [    1.872480] pata_isapnp 01:01.02: activated
      [    1.889823] scsi2 : pata_isapnp
      [    1.890109] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
      [    6.888110] ata3.01: qc timeout (cmd 0xec)
      [    6.888179] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   16.888085] ata3.01: qc timeout (cmd 0xec)
      [   16.888147] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   46.888086] ata3.01: qc timeout (cmd 0xec)
      [   46.888148] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   51.888100] ata3.00: qc timeout (cmd 0xec)
      [   51.888160] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   61.888079] ata3.00: qc timeout (cmd 0xec)
      [   61.888141] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   91.888089] ata3.00: qc timeout (cmd 0xec)
      [   91.888152] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
      
      ATAPI device connected:
      [    1.882061] pata_isapnp 01:01.02: activated
      [    1.893430] scsi2 : pata_isapnp
      [    1.893719] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
      [    6.892107] ata3.01: qc timeout (cmd 0xec)
      [    6.892171] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   16.892079] ata3.01: qc timeout (cmd 0xec)
      [   16.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   46.892079] ata3.01: qc timeout (cmd 0xec)
      [   46.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
      [   46.908586] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr
      [   46.924570] ata3.00: configured for PIO0 (device error ignored)
      [   46.926295] scsi 2:0:0:0: CD-ROM            ACER     CD-767E/O        1.5X PQ: 0 ANSI: 5
      [   46.984519] sr0: scsi3-mmc drive: 6x/6x xa/form2 tray
      [   46.984592] cdrom: Uniform CD-ROM driver Revision: 3.20
      
      So don't skip ata_sff_softreset, just skip the reset part of ata_bus_softreset
      if the ctl port is not available.
      
      This makes IDE port on ES968 behave correctly:
      
      No device connected:
      [    4.670888] pata_isapnp 01:01.02: activated
      [    4.673207] scsi host2: pata_isapnp
      [    4.673675] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
      [    7.081840] Adding 2541652k swap on /dev/sda2.  Priority:-1 extents:1 across:2541652k
      
      ATAPI device connected:
      [    4.704362] pata_isapnp 01:01.02: activated
      [    4.706620] scsi host2: pata_isapnp
      [    4.706877] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
      [    4.872782] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr
      [    4.888673] ata3.00: configured for PIO0 (device error ignored)
      [    4.893984] scsi 2:0:0:0: CD-ROM            ACER     CD-767E/O        1.5X PQ: 0 ANSI: 5
      [    7.015578] Adding 2541652k swap on /dev/sda2.  Priority:-1 extents:1 across:2541652k
      Signed-off-by: default avatarOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      07c3adf1
    • Scott Carter's avatar
      pata_serverworks: disable 64-KB DMA transfers on Broadcom OSB4 IDE Controller · 6b8c81e2
      Scott Carter authored
      commit 37017ac6 upstream.
      
      The Broadcom OSB4 IDE Controller (vendor and device IDs: 1166:0211)
      does not support 64-KB DMA transfers.
      Whenever a 64-KB DMA transfer is attempted,
      the transfer fails and messages similar to the following
      are written to the console log:
      
         [ 2431.851125] sr 0:0:0:0: [sr0] Unhandled sense code
         [ 2431.851139] sr 0:0:0:0: [sr0]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
         [ 2431.851152] sr 0:0:0:0: [sr0]  Sense Key : Hardware Error [current]
         [ 2431.851166] sr 0:0:0:0: [sr0]  Add. Sense: Logical unit communication time-out
         [ 2431.851182] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 76 f4 00 00 40 00
         [ 2431.851210] end_request: I/O error, dev sr0, sector 121808
      
      When the libata and pata_serverworks modules
      are recompiled with ATA_DEBUG and ATA_VERBOSE_DEBUG defined in libata.h,
      the 64-KB transfer size in the scatter-gather list can be seen
      in the console log:
      
         [ 2664.897267] sr 9:0:0:0: [sr0] Send:
         [ 2664.897274] 0xf63d85e0
         [ 2664.897283] sr 9:0:0:0: [sr0] CDB:
         [ 2664.897288] Read(10): 28 00 00 00 7f b4 00 00 40 00
         [ 2664.897319] buffer = 0xf6d6fbc0, bufflen = 131072, queuecommand 0xf81b7700
         [ 2664.897331] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 7f b4 00 00 40
         [ 2664.897338] ata_scsi_translate: ENTER
         [ 2664.897345] ata_sg_setup: ENTER, ata1
         [ 2664.897356] ata_sg_setup: 3 sg elements mapped
         [ 2664.897364] ata_bmdma_fill_sg: PRD[0] = (0x66FD2000, 0xE000)
         [ 2664.897371] ata_bmdma_fill_sg: PRD[1] = (0x65000000, 0x10000)
         ------------------------------------------------------> =======
         [ 2664.897378] ata_bmdma_fill_sg: PRD[2] = (0x66A10000, 0x2000)
         [ 2664.897386] ata1: ata_dev_select: ENTER, device 0, wait 1
         [ 2664.897422] ata_sff_tf_load: feat 0x1 nsect 0x0 lba 0x0 0x0 0xFC
         [ 2664.897428] ata_sff_tf_load: device 0xA0
         [ 2664.897448] ata_sff_exec_command: ata1: cmd 0xA0
         [ 2664.897457] ata_scsi_translate: EXIT
         [ 2664.897462] leaving scsi_dispatch_cmnd()
         [ 2664.897497] Doing sr request, dev = sr0, block = 0
         [ 2664.897507] sr0 : reading 64/256 512 byte blocks.
         [ 2664.897553] ata_sff_hsm_move: ata1: protocol 7 task_state 1 (dev_stat 0x58)
         [ 2664.897560] atapi_send_cdb: send cdb
         [ 2666.910058] ata_bmdma_port_intr: ata1: host_stat 0x64
         [ 2666.910079] __ata_sff_port_intr: ata1: protocol 7 task_state 3
         [ 2666.910093] ata_sff_hsm_move: ata1: protocol 7 task_state 3 (dev_stat 0x51)
         [ 2666.910101] ata_sff_hsm_move: ata1: protocol 7 task_state 4 (dev_stat 0x51)
         [ 2666.910129] sr 9:0:0:0: [sr0] Done:
         [ 2666.910136] 0xf63d85e0 TIMEOUT
      
      lspci shows that the driver used for the Broadcom OSB4 IDE Controller is
      pata_serverworks:
      
         00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8e [Master SecP SecO PriP])
                 Flags: bus master, medium devsel, latency 64
                 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
                 [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
                 I/O ports at 0170 [size=8]
                 I/O ports at 0374 [size=4]
                 I/O ports at 1440 [size=16]
                 Kernel driver in use: pata_serverworks
      
      The pata_serverworks driver supports five distinct device IDs,
      one being the OSB4 and the other four belonging to the CSB series.
      The CSB series appears to support 64-KB DMA transfers,
      as tests on a machine with an SAI2 motherboard
      containing a Broadcom CSB5 IDE Controller (vendor and device IDs: 1166:0212)
      showed no problems with 64-KB DMA transfers.
      
      This problem was first discovered when attempting to install openSUSE
      from a DVD on a machine with an STL2 motherboard.
      Using the pata_serverworks module,
      older releases of openSUSE will not install at all due to the timeouts.
      Releases of openSUSE prior to 11.3 can be installed by disabling
      the pata_serverworks module using the brokenmodules boot parameter,
      which causes the serverworks module to be used instead.
      Recent releases of openSUSE (12.2 and later) include better error recovery and
      will install, though very slowly.
      On all openSUSE releases, the problem can be recreated
      on a machine containing a Broadcom OSB4 IDE Controller
      by mounting an install DVD and running a command similar to the following:
      
         find /mnt -type f -print | xargs cat > /dev/null
      
      The patch below corrects the problem.
      Similar to the other ATA drivers that do not support 64-KB DMA transfers,
      the patch changes the ata_port_operations qc_prep vector to point to a routine
      that breaks any 64-KB segment into two 32-KB segments and
      changes the scsi_host_template sg_tablesize element to reduce by half
      the number of scatter/gather elements allowed.
      These two changes affect only the OSB4.
      Signed-off-by: default avatarScott Carter <ccscott@funsoft.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6b8c81e2
    • Guenter Roeck's avatar
      Revert "percpu: free percpu allocation info for uniprocessor system" · 8fb1d89e
      Guenter Roeck authored
      commit bb2e226b upstream.
      
      This reverts commit 3189eddb ("percpu: free percpu allocation info for
      uniprocessor system").
      
      The commit causes a hang with a crisv32 image. This may be an architecture
      problem, but at least for now the revert is necessary to be able to boot a
      crisv32 image.
      
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Honggang Li <enjoymindful@gmail.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Fixes: 3189eddb ("percpu: free percpu allocation info for uniprocessor system")
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8fb1d89e
    • Trond Myklebust's avatar
      SUNRPC: Add missing support for RPC_CLNT_CREATE_NO_RETRANS_TIMEOUT · 48291fa9
      Trond Myklebust authored
      commit 2aca5b86 upstream.
      
      The flag RPC_CLNT_CREATE_NO_RETRANS_TIMEOUT was intended introduced in
      order to allow NFSv4 clients to disable resend timeouts. Since those
      cause the RPC layer to break the connection, they mess up the duplicate
      reply caches that remain indexed on the port number in NFSv4..
      
      This patch includes the code that was missing in the original to
      set the appropriate flag in struct rpc_clnt, when the caller of
      rpc_create() sets RPC_CLNT_CREATE_NO_RETRANS_TIMEOUT.
      
      Fixes: 8a19a0b6 (SUNRPC: Add RPC task and client level options to...)
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      48291fa9
    • Benjamin Coddington's avatar
      SUNRPC: Don't wake tasks during connection abort · 0b37ceb8
      Benjamin Coddington authored
      commit a743419f upstream.
      
      When aborting a connection to preserve source ports, don't wake the task in
      xs_error_report.  This allows tasks with RPC_TASK_SOFTCONN to succeed if the
      connection needs to be re-established since it preserves the task's status
      instead of setting it to the status of the aborting kernel_connect().
      
      This may also avoid a potential conflict on the socket's lock.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0b37ceb8
    • Benjamin Coddington's avatar
      lockd: Try to reconnect if statd has moved · e7b7a6dd
      Benjamin Coddington authored
      commit 173b3afc upstream.
      
      If rpc.statd is restarted, upcalls to monitor hosts can fail with
      ECONNREFUSED.  In that case force a lookup of statd's new port and retry the
      upcall.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e7b7a6dd
    • Michel Dänzer's avatar
      drm/ttm: Don't evict BOs outside of the requested placement range · ebc39080
      Michel Dänzer authored
      commit e300180f upstream.
      
      The radeon driver uses placement range restrictions for several reasons,
      in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
      during a page fault.
      
      Without this change, TTM could evict other BOs while trying to satisfy
      the requested placement, even if the evicted BOs were outside of the
      requested placement range. Doing so didn't free up any space in the
      requested placement range, so the (potentially high) eviction cost was
      incurred for no benefit.
      
      Nominating for stable because radeon driver changes in 3.17 made this
      much more noticeable than before.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      [ luis: backported to 3.16: based on Michel's backport ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ebc39080