1. 16 Sep, 2014 1 commit
    • Richard Genoud's avatar
      UBI: add missing kmem_cache_free() in process_pool_aeb error path · 1bf1890e
      Richard Genoud authored
      I ran into this error after a ubiupdatevol, because I forgot to backport
      e9110361 UBI: fix the volumes tree sorting criteria.
      
      UBI error: process_pool_aeb: orphaned volume in fastmap pool
      UBI error: ubi_scan_fastmap: Attach by fastmap failed, doing a full scan!
      kmem_cache_destroy ubi_ainf_peb_slab: Slab cache still has objects
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.18-00053-gf05cac8dbf85 #1
      [<c000d298>] (unwind_backtrace) from [<c000baa8>] (show_stack+0x10/0x14)
      [<c000baa8>] (show_stack) from [<c01b7a68>] (destroy_ai+0x230/0x244)
      [<c01b7a68>] (destroy_ai) from [<c01b8fd4>] (ubi_attach+0x98/0x1ec)
      [<c01b8fd4>] (ubi_attach) from [<c01ade90>] (ubi_attach_mtd_dev+0x2b8/0x868)
      [<c01ade90>] (ubi_attach_mtd_dev) from [<c038b510>] (ubi_init+0x1dc/0x2ac)
      [<c038b510>] (ubi_init) from [<c0008860>] (do_one_initcall+0x94/0x140)
      [<c0008860>] (do_one_initcall) from [<c037aadc>] (kernel_init_freeable+0xe8/0x1b0)
      [<c037aadc>] (kernel_init_freeable) from [<c02730ac>] (kernel_init+0x8/0xe4)
      [<c02730ac>] (kernel_init) from [<c00093f0>] (ret_from_fork+0x14/0x24)
      UBI: scanning is finished
      
      Freeing the cache in the error path fixes the Slab error.
      
      Tested on at91sam9g35 (3.14.18+fastmap backports)
      Signed-off-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Cc: stable <stable@vger.kernel.org> # 3.10+
      1bf1890e
  2. 08 Sep, 2014 2 commits
    • Artem Bityutskiy's avatar
      UBIFS: fix free log space calculation · ba29e721
      Artem Bityutskiy authored
      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.
      
      Cc: stable@vger.kernel.org
      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>
      ba29e721
    • Artem Bityutskiy's avatar
      UBIFS: fix a race condition · 052c2807
      Artem Bityutskiy authored
      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).
      
      Cc: stable@vger.kernel.org # 07e19dff UBIFS: remove mst_mutex
      Cc: stable@vger.kernel.org
      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>
      052c2807
  3. 07 Sep, 2014 11 commits
  4. 06 Sep, 2014 6 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 2b12164b
      Linus Torvalds authored
      Pull kvm fixes from Paolo Bonzini:
       "A smattering of bug fixes across most architectures"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        powerpc/kvm/cma: Fix panic introduces by signed shift operation
        KVM: s390/mm: Fix guest storage key corruption in ptep_set_access_flags
        KVM: s390/mm: Fix storage key corruption during swapping
        arm/arm64: KVM: Complete WFI/WFE instructions
        ARM/ARM64: KVM: Nuke Hyp-mode tlbs before enabling MMU
        KVM: s390/mm: try a cow on read only pages for key ops
        KVM: s390: Fix user triggerable bug in dead code
      2b12164b
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 56c22854
      Linus Torvalds authored
      Pull ARM SoC fixes from Kevin Hilman:
       "Another round of fixes from arm-soc land, which are mostly DT fixes
        for:
      
         - OMAP: handful of DT fixes devices on newly supported hardware
         - davinci: fix 2nd EDMA channel
         - ux500: extend previous pinctrl fix to another board
         - at91: clock registration fixes, compatibility string precision
      
        And one more fix for event cleanup in drivers/bus/arm-ccn"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        bus: arm-ccn: Move event cleanup routine
        ARM: at91/dt: rm9200: fix usb clock definition
        ARM: at91: rm9200: fix clock registration
        ARM: at91/dt: sam9g20: set at91sam9g20 pllb driver
        ARM: dts: dra7-evm: Add vtt regulator support
        ARM: dts: dra7-evm: Fix spi1 mux documentation
        ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with GPMC-NAND
        ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring
        ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring
        ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
        ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8
        ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8
        ARM: dts: am4372: fix USB regs size
        ARM: dts: am437x-gp: switch i2c0 to 100KHz
        ARM: dts: dra7-evm: Fix 8th NAND partition's name
        ARM: dts: dra7-evm: Fix i2c3 pinmux and frequency
        ARM: ux500: disable msp2 node on Snowball
        ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC
        ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
      56c22854
    • Linus Torvalds's avatar
      Merge tag 'xfs-for-linus-3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs · 11e97398
      Linus Torvalds authored
      Pull xfs fixes from Dave Chinner:
       "The fixes all address recently discovered data corruption issues.
      
        The original Direct IO issue was discovered by Chris Mason @ Facebook
        on a production workload which mixed buffered reads with direct reads
        and writes IO to the same file.  The fix for that exposed other issues
        with page invalidation (exposed by millions of fsx operations) failing
        due to dirty buffers beyond EOF.
      
        Finally, the collapse_range code could also cause problems due to
        racing writeback changing the extent map while it was being shifted
        around.  The commits for that problem are simple mitigation fixes that
        prevent the problem from occuring.  A more robust fix for 3.18 that
        addresses the underlying problem is currently being worked on by
        Brian.
      
        Summary of fixes:
         - a direct IO read/buffered read data corruption
         - the associated fallout from the DIO data corruption fix
         - collapse range bugs that are potential data corruption issues"
      
      * tag 'xfs-for-linus-3.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs:
        xfs: trim eofblocks before collapse range
        xfs: xfs_file_collapse_range is delalloc challenged
        xfs: don't log inode unless extent shift makes extent modifications
        xfs: use ranged writeback and invalidation for direct IO
        xfs: don't zero partial page cache pages during O_DIRECT writes
        xfs: don't zero partial page cache pages during O_DIRECT writes
        xfs: don't dirty buffers beyond EOF
      11e97398
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20140905' of git://git.infradead.org/linux-mtd · 925e0ea4
      Linus Torvalds authored
      Pull mtd fixes from Brian Norris:
       "Two trivial MTD updates for 3.17-rc4:
      
         - a tiny comment tweak, to kill a bunch of DocBook warnings added
           during the merge window
      
         - a small fixup to the OTP routines' error handling"
      
      * tag 'for-linus-20140905' of git://git.infradead.org/linux-mtd:
        mtd: nand: fix DocBook warnings on nand_sdr_timings doc
        mtd: cfi_cmdset_0002: check return code for get_chip()
      925e0ea4
    • Thomas Gleixner's avatar
      timekeeping: Update timekeeper before updating vsyscall and pvclock · 9bf2419f
      Thomas Gleixner authored
      The update_walltime() code works on the shadow timekeeper to make the
      seqcount protected region as short as possible. But that update to the
      shadow timekeeper does not update all timekeeper fields because it's
      sufficient to do that once before it becomes life. One of these fields
      is tkr.base_mono. That stays stale in the shadow timekeeper unless an
      operation happens which copies the real timekeeper to the shadow.
      
      The update function is called after the update calls to vsyscall and
      pvclock. While not correct, it did not cause any problems because none
      of the invoked update functions used base_mono.
      
      commit cbcf2dd3 (x86: kvm: Make kvm_get_time_and_clockread()
      nanoseconds based) changed that in the kvm pvclock update function, so
      the stale mono_base value got used and caused kvm-clock to malfunction.
      
      Put the update where it belongs and fix the issue.
      Reported-by: default avatarChris J Arges <chris.j.arges@canonical.com>
      Reported-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409050000570.3333@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      9bf2419f
    • Thomas Gleixner's avatar
      compat: nanosleep: Clarify error handling · 849151dd
      Thomas Gleixner authored
      The error handling in compat_sys_nanosleep() is correct, but
      completely non obvious. Document it and restrict it to the
      -ERESTART_RESTARTBLOCK return value for clarity.
      Reported-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      849151dd
  5. 05 Sep, 2014 17 commits
  6. 04 Sep, 2014 3 commits