1. 17 Nov, 2014 24 commits
    • Emil Velikov's avatar
      drm/nouveau/gpio: rename g92 class to g94 · 3b9a8b7e
      Emil Velikov authored
      commit b485a700 upstream.
      
      nv92 hardware has only 16 interrupt lines, while nv94 and later
      has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect
      PDISP setup. This is a regression introduced with
      
      commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3
      Author: Ben Skeggs <bskeggs@redhat.com>
      Date:   Mon May 12 15:22:42 2014 +1000
      
          gpio: split g92 class from nv50
      
      Reported-by: estece on #nouveau
      Signed-off-by: default avatarEmil Velikov <emil.l.velikov@gmail.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3b9a8b7e
    • Benjamin Herrenschmidt's avatar
      drm/ast: Fix HW cursor image · e58e777b
      Benjamin Herrenschmidt authored
      commit 1e99cfa8 upstream.
      
      The translation from the X driver to the KMS one typo'ed a couple
      of array indices, causing the HW cursor to look weird (blocky with
      leaking edge colors). This fixes it.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e58e777b
    • Hans de Goede's avatar
      Input: i8042 - add noloop quirk for Asus X750LN · e1c9aa44
      Hans de Goede authored
      commit 9ff84a17 upstream.
      
      Without this the aux port does not get detected, and consequently the
      touchpad will not work.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1110011Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e1c9aa44
    • Dmitry Torokhov's avatar
      Input: synaptics - gate forcepad support by DMI check · 332221c6
      Dmitry Torokhov authored
      commit aa972409 upstream.
      
      Unfortunately, ForcePad capability is not actually exported over PS/2, so
      we have to resort to DMI checks.
      Reported-by: default avatarNicole Faerber <nicole.faerber@kernelconcepts.de>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      332221c6
    • Mikulas Patocka's avatar
      framebuffer: fix border color · 4187f126
      Mikulas Patocka authored
      commit f74a289b upstream.
      
      The framebuffer code uses the current background color to fill the border
      when switching consoles, however, this results in inconsistent behavior.
      For example:
      - start Midnigh Commander
      - the border is black
      - switch to another console and switch back
      - the border is cyan
      - type something into the command line in mc
      - the border is cyan
      - switch to another console and switch back
      - the border is black
      - press F9 to go to menu
      - the border is black
      - switch to another console and switch back
      - the border is dark blue
      
      When switching to a console with Midnight Commander, the border is random
      color that was left selected by the slang subsystem.
      
      This patch fixes this inconsistency by always using black as the
      background color when switching consoles.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4187f126
    • Mikulas Patocka's avatar
      framebuffer: fix screen corruption when copying · 450c8ecd
      Mikulas Patocka authored
      commit 5b789da8 upstream.
      
      The function bitcpy_rev has a bug that may result in screen corruption.
      The bug happens under these conditions:
      * the end of the destination area of a copy operation is aligned on a long
        word boundary
      * the end of the source area is not aligned on a long word boundary
      * we are copying more than one long word
      
      In this case, the variable shift is non-zero and the variable first is
      zero. The statements FB_WRITEL(comp(d0, FB_READL(dst), first), dst) reads
      the last long word of the destination and writes it back unchanged
      (because first is zero). Correctly, we should write the variable d0 to the
      last word of the destination in this case.
      
      This patch fixes the bug by introducing and extra test if first is zero.
      
      The patch also removes the references to fb_memmove in the code that is
      commented out because fb_memmove was removed from framebuffer subsystem.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      450c8ecd
    • Prarit Bhargava's avatar
      modules, lock around setting of MODULE_STATE_UNFORMED · c5029ed4
      Prarit Bhargava authored
      commit d3051b48 upstream.
      
      A panic was seen in the following sitation.
      
      There are two threads running on the system. The first thread is a system
      monitoring thread that is reading /proc/modules. The second thread is
      loading and unloading a module (in this example I'm using my simple
      dummy-module.ko).  Note, in the "real world" this occurred with the qlogic
      driver module.
      
      When doing this, the following panic occurred:
      
       ------------[ cut here ]------------
       kernel BUG at kernel/module.c:3739!
       invalid opcode: 0000 [#1] SMP
       Modules linked in: binfmt_misc sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw igb gf128mul glue_helper iTCO_wdt iTCO_vendor_support ablk_helper ptp sb_edac cryptd pps_core edac_core shpchp i2c_i801 pcspkr wmi lpc_ich ioatdma mfd_core dca ipmi_si nfsd ipmi_msghandler auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm isci drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: dummy_module]
       CPU: 37 PID: 186343 Comm: cat Tainted: GF          O--------------   3.10.0+ #7
       Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
       task: ffff8807fd2d8000 ti: ffff88080fa7c000 task.ti: ffff88080fa7c000
       RIP: 0010:[<ffffffff810d64c5>]  [<ffffffff810d64c5>] module_flags+0xb5/0xc0
       RSP: 0018:ffff88080fa7fe18  EFLAGS: 00010246
       RAX: 0000000000000003 RBX: ffffffffa03b5200 RCX: 0000000000000000
       RDX: 0000000000001000 RSI: ffff88080fa7fe38 RDI: ffffffffa03b5000
       RBP: ffff88080fa7fe28 R08: 0000000000000010 R09: 0000000000000000
       R10: 0000000000000000 R11: 000000000000000f R12: ffffffffa03b5000
       R13: ffffffffa03b5008 R14: ffffffffa03b5200 R15: ffffffffa03b5000
       FS:  00007f6ae57ef740(0000) GS:ffff88101e7a0000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000404f70 CR3: 0000000ffed48000 CR4: 00000000001407e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Stack:
        ffffffffa03b5200 ffff8810101e4800 ffff88080fa7fe70 ffffffff810d666c
        ffff88081e807300 000000002e0f2fbf 0000000000000000 ffff88100f257b00
        ffffffffa03b5008 ffff88080fa7ff48 ffff8810101e4800 ffff88080fa7fee0
       Call Trace:
        [<ffffffff810d666c>] m_show+0x19c/0x1e0
        [<ffffffff811e4d7e>] seq_read+0x16e/0x3b0
        [<ffffffff812281ed>] proc_reg_read+0x3d/0x80
        [<ffffffff811c0f2c>] vfs_read+0x9c/0x170
        [<ffffffff811c1a58>] SyS_read+0x58/0xb0
        [<ffffffff81605829>] system_call_fastpath+0x16/0x1b
       Code: 48 63 c2 83 c2 01 c6 04 03 29 48 63 d2 eb d9 0f 1f 80 00 00 00 00 48 63 d2 c6 04 13 2d 41 8b 0c 24 8d 50 02 83 f9 01 75 b2 eb cb <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
       RIP  [<ffffffff810d64c5>] module_flags+0xb5/0xc0
        RSP <ffff88080fa7fe18>
      
          Consider the two processes running on the system.
      
          CPU 0 (/proc/modules reader)
          CPU 1 (loading/unloading module)
      
          CPU 0 opens /proc/modules, and starts displaying data for each module by
          traversing the modules list via fs/seq_file.c:seq_open() and
          fs/seq_file.c:seq_read().  For each module in the modules list, seq_read
          does
      
                  op->start()  <-- this is a pointer to m_start()
                  op->show()   <- this is a pointer to m_show()
                  op->stop()   <-- this is a pointer to m_stop()
      
          The m_start(), m_show(), and m_stop() module functions are defined in
          kernel/module.c. The m_start() and m_stop() functions acquire and release
          the module_mutex respectively.
      
          ie) When reading /proc/modules, the module_mutex is acquired and released
          for each module.
      
          m_show() is called with the module_mutex held.  It accesses the module
          struct data and attempts to write out module data.  It is in this code
          path that the above BUG_ON() warning is encountered, specifically m_show()
          calls
      
          static char *module_flags(struct module *mod, char *buf)
          {
                  int bx = 0;
      
                  BUG_ON(mod->state == MODULE_STATE_UNFORMED);
          ...
      
          The other thread, CPU 1, in unloading the module calls the syscall
          delete_module() defined in kernel/module.c.  The module_mutex is acquired
          for a short time, and then released.  free_module() is called without the
          module_mutex.  free_module() then sets mod->state = MODULE_STATE_UNFORMED,
          also without the module_mutex.  Some additional code is called and then the
          module_mutex is reacquired to remove the module from the modules list:
      
              /* Now we can delete it from the lists */
              mutex_lock(&module_mutex);
              stop_machine(__unlink_module, mod, NULL);
              mutex_unlock(&module_mutex);
      
      This is the sequence of events that leads to the panic.
      
      CPU 1 is removing dummy_module via delete_module().  It acquires the
      module_mutex, and then releases it.  CPU 1 has NOT set dummy_module->state to
      MODULE_STATE_UNFORMED yet.
      
      CPU 0, which is reading the /proc/modules, acquires the module_mutex and
      acquires a pointer to the dummy_module which is still in the modules list.
      CPU 0 calls m_show for dummy_module.  The check in m_show() for
      MODULE_STATE_UNFORMED passed for dummy_module even though it is being
      torn down.
      
      Meanwhile CPU 1, which has been continuing to remove dummy_module without
      holding the module_mutex, now calls free_module() and sets
      dummy_module->state to MODULE_STATE_UNFORMED.
      
      CPU 0 now calls module_flags() with dummy_module and ...
      
      static char *module_flags(struct module *mod, char *buf)
      {
              int bx = 0;
      
              BUG_ON(mod->state == MODULE_STATE_UNFORMED);
      
      and BOOM.
      
      Acquire and release the module_mutex lock around the setting of
      MODULE_STATE_UNFORMED in the teardown path, which should resolve the
      problem.
      
      Testing: In the unpatched kernel I can panic the system within 1 minute by
      doing
      
      while (true) do insmod dummy_module.ko; rmmod dummy_module.ko; done
      
      and
      
      while (true) do cat /proc/modules; done
      
      in separate terminals.
      
      In the patched kernel I was able to run just over one hour without seeing
      any issues.  I also verified the output of panic via sysrq-c and the output
      of /proc/modules looks correct for all three states for the dummy_module.
      
              dummy_module 12661 0 - Unloading 0xffffffffa03a5000 (OE-)
              dummy_module 12661 0 - Live 0xffffffffa03bb000 (OE)
              dummy_module 14015 1 - Loading 0xffffffffa03a5000 (OE+)
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c5029ed4
    • Alexey Khoroshilov's avatar
      dm log userspace: fix memory leak in dm_ulog_tfr_init failure path · 04b2550a
      Alexey Khoroshilov authored
      commit 56ec16cb upstream.
      
      If cn_add_callback() fails in dm_ulog_tfr_init(), it does not
      deallocate prealloced memory but calls cn_del_callback().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Reviewed-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      04b2550a
    • Mike Snitzer's avatar
      block: fix alignment_offset math that assumes io_min is a power-of-2 · 4296b616
      Mike Snitzer authored
      commit b8839b8c upstream.
      
      The math in both blk_stack_limits() and queue_limit_alignment_offset()
      assume that a block device's io_min (aka minimum_io_size) is always a
      power-of-2.  Fix the math such that it works for non-power-of-2 io_min.
      
      This issue (of alignment_offset != 0) became apparent when testing
      dm-thinp with a thinp blocksize that matches a RAID6 stripesize of
      1280K.  Commit fdfb4c8c ("dm thin: set minimum_io_size to pool's data
      block size") unlocked the potential for alignment_offset != 0 due to
      the dm-thin-pool's io_min possibly being a non-power-of-2.
      Signed-off-by: default avatarMike Snitzer <snitzer@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 avatarLuis Henriques <luis.henriques@canonical.com>
      4296b616
    • Lai Jiangshan's avatar
      drbd: compute the end before rb_insert_augmented() · 51edc20f
      Lai Jiangshan authored
      commit 82cfb90b upstream.
      
      Commit 98683650 "Merge branch 'drbd-8.4_ed6' into
      for-3.8-drivers-drbd-8.4_ed6" switches to the new augment API, but the
      new API requires that the tree is augmented before rb_insert_augmented()
      is called, which is missing.
      
      So we add the augment-code to drbd_insert_interval() when it travels the
      tree up to down before rb_insert_augmented().  See the example in
      include/linux/interval_tree_generic.h or Documentation/rbtree.txt.
      
      drbd_insert_interval() may cancel the insertion when traveling, in this
      case, the just added augment-code does nothing before cancel since the
      @this node is already in the subtrees in this case.
      
      CC: Michel Lespinasse <walken@google.com>
      Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@linbit.com>
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      51edc20f
    • Mikulas Patocka's avatar
      dm bufio: when done scanning return from __scan immediately · 397c6bba
      Mikulas Patocka authored
      commit 0e825862 upstream.
      
      When __scan frees the required number of buffer entries that the
      shrinker requested (nr_to_scan becomes zero) it must return.  Before
      this fix the __scan code exited only the inner loop and continued in the
      outer loop -- which could result in reduced performance due to extra
      buffers being freed (e.g. unnecessarily evicted thinp metadata needing
      to be synchronously re-read into bufio's cache).
      
      Also, move dm_bufio_cond_resched to __scan's inner loop, so that
      iterating the bufio client's lru lists doesn't result in scheduling
      latency.
      Reported-by: default avatarJoe Thornber <thornber@redhat.com>
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      397c6bba
    • Joe Thornber's avatar
      dm bufio: update last_accessed when relinking a buffer · fd5d12b9
      Joe Thornber authored
      commit eb76faf5 upstream.
      
      The 'last_accessed' member of the dm_buffer structure was only set when
      the the buffer was created.  This led to each buffer being discarded
      after dm_bufio_max_age time even if it was used recently.  In practice
      this resulted in all thinp metadata being evicted soon after being read
      -- this is particularly problematic for metadata intensive workloads
      like multithreaded small random IO.
      
      'last_accessed' is now updated each time the buffer is moved to the head
      of the LRU list, so the buffer is now properly discarded if it was not
      used in dm_bufio_max_age time.
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fd5d12b9
    • 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 16 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