All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 28 Apr, 2016 31 commits
  2. 27 Apr, 2016 9 commits
    • Linus Torvalds's avatar
      Merge branch 'for-4.6-fixes' of git:// · b75a2bf8
      Linus Torvalds authored
      Pull workqueue fix from Tejun Heo:
       "So, it turns out we had a silly bug in the most fundamental part of
        workqueue for a very long time.  AFAICS, this dates back to pre-git
        era and has quite likely been there from the time workqueue was first
        A work item uses its PENDING bit to synchronize multiple queuers.
        Anyone who wins the PENDING bit owns the pending state of the work
        item.  Whether a queuer wins or loses the race, one thing should be
        guaranteed - there will soon be at least one execution of the work
        item - where "after" means that the execution instance would be able
        to see all the changes that the queuer has made prior to the queueing
        Unfortunately, we were missing a smp_mb() after clearing PENDING for
        execution, so nothing guaranteed visibility of the changes that a
        queueing loser has made, which manifested as a reproducible blk-mq
        Lots of kudos to Roman for debugging the problem.  The patch for
        -stable is the minimal one.  For v3.7, Peter is working on a patch to
        make the code path slightly more efficient and less fragile"
      * 'for-4.6-fixes' of git://
        workqueue: fix ghost PENDING flag while doing MQ IO
    • Linus Torvalds's avatar
      Merge branch 'for-4.6-fixes' of git:// · 763cfc86
      Linus Torvalds authored
      Pull cgroup fixes from Tejun Heo:
       "Two patches to fix a deadlock which can be easily triggered if memcg
        charge moving is used.
        This bug was introduced while converting threadgroup locking to a
        global percpu_rwsem and is caused by cgroup controller task migration
        path depending on the ability to create new kthreads.  cpuset had a
        similar issue which was fixed by performing heavy-lifting operations
        asynchronous to task migration.  The two patches fix the same issue in
        memcg in a similar way.  The first patch makes the mechanism generic
        and the second relocates memcg charge moving outside the migration
        Given that we don't want to perform heavy operations while
        writelocking threadgroup lock anyway, moving them out of the way is a
        desirable solution.  One thing to note is that the problem was
        difficult to debug because lockdep couldn't figure out the deadlock
        condition.  Looking into how to improve that"
      * 'for-4.6-fixes' of git://
        memcg: relocate charge moving from ->attach to ->post_attach
        cgroup, cpuset: replace cpuset_post_attach_flush() with cgroup_subsys->post_attach callback
    • Linus Torvalds's avatar
      Merge branch 'i2c/for-current' of git:// · 3118e5f9
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "I2C has one buildfix, one ABBA deadlock fix, and three simple 'add ID'
      * 'i2c/for-current' of git://
        i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
        i2c: cpm: Fix build break due to incompatible pointer types
        i2c: ismt: Add Intel DNV PCI ID
        i2c: xlp9xx: add support for Broadcom Vulcan
        i2c: rk3x: add support for rk3228
    • Linus Torvalds's avatar
      Merge tag 'arc-4.6-rc6-fixes' of git:// · 24131a61
      Linus Torvalds authored
      Pull ARC fixes from Vineet Gupta:
       - lockdep now works for ARCv2 builds
       - enable DT reserved-memory binding (for forthcoming HDMI driver)
      * tag 'arc-4.6-rc6-fixes' of git://
        ARC: add support for reserved memory defined by device tree
        ARC: support generic per-device coherent dma mem
        Documentation: dt: arc: fix spelling mistakes
        ARCv2: Enable LOCKDEP
    • Linus Torvalds's avatar
      Merge tag 'nios2-v4.6-fix' of git:// · 508fea71
      Linus Torvalds authored
      Pull arch/nios2 fix from Ley Foon Tan:
       "memset: use the right constraint modifier for the %4 output operand"
      * tag 'nios2-v4.6-fix' of git://
        nios2: memset: use the right constraint modifier for the %4 output operand
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v4.6-3' of... · 9453203b
      Linus Torvalds authored
      Merge tag 'platform-drivers-x86-v4.6-3' of git://
      Pull x86 platform driver fix from Darren Hart:
       "Fix regression caused by hotkey enabling value in toshiba_acpi"
      * tag 'platform-drivers-x86-v4.6-3' of git://
        toshiba_acpi: Fix regression caused by hotkey enabling value
    • Alexey Brodkin's avatar
      ARC: add support for reserved memory defined by device tree · 1b10cb21
      Alexey Brodkin authored
      Enable reserved memory initialization from device tree.
      Signed-off-by: default avatarAlexey Brodkin <>
      Cc: Grant Likely <>
      Cc: Marek Szyprowski <>
      Signed-off-by: default avatarVineet Gupta <>
    • Alexey Brodkin's avatar
      ARC: support generic per-device coherent dma mem · 32ed9a0e
      Alexey Brodkin authored
      Signed-off-by: default avatarAlexey Brodkin <>
      Signed-off-by: default avatarVineet Gupta <>
    • Romain Perier's avatar
      nios2: memset: use the right constraint modifier for the %4 output operand · a8950e49
      Romain Perier authored
      Depending on the size of the area to be memset'ed, the nios2 memset implementation
      either uses a naive loop (for buffers smaller or equal than 8 bytes) or a more optimized
      implementation (for buffers larger than 8 bytes). This implementation does 4-byte stores
      rather than 1-byte stores to speed up memset.
      However, we discovered that on our nios2 platform, memset() was not properly setting the
      buffer to the expected value. A memset of 0xff would not set the entire buffer to 0xff, but to:
      0xff 0x00 0xff 0x00 0xff 0x00 0xff 0x00 ...
      Which is obviously incorrect. Our investigation has revealed that the problem lies in the
      incorrect constraints used in the inline assembly.
      The following piece of assembly, from the nios2 memset implementation, is supposed to
      create a 4-byte value that repeats 4 times the 1-byte pattern passed as memset argument:
      /* fill8 %3, %5 (c & 0xff) */
      "       slli    %4, %5, 8\n"
      "       or      %4, %4, %5\n"
      "       slli    %3, %4, 16\n"
      "       or      %3, %3, %4\n"
      However, depending on the compiler and optimization level, this code might be compiled as:
      34:	280a923a 	slli	r5,r5,8
      38:	294ab03a 	or	r5,r5,r5
      3c:	2808943a 	slli	r4,r5,16
      40:	2148b03a 	or	r4,r4,r5
      This is wrong because r5 gets used both for %5 and %4, which leads to the final pattern
      stored in r4 to be 0xff00ff00 rather than the expected 0xffffffff.
      %4 is defined with the "=r" constraint, i.e as an output operand. However, as explained in, this does not prevent gcc from
      using the same register for an output operand (%4) and input operand (%5). By using the
      constraint modifier '&', we indicate that the register should be used for output only. With this
      change, we get the following assembly output:
      34:	2810923a 	slli	r8,r5,8
      38:	4150b03a 	or	r8,r8,r5
      3c:	400e943a 	slli	r7,r8,16
      40:	3a0eb03a 	or	r7,r7,r8
      Which correctly produces the 0xffffffff pattern when 0xff is passed as the memset() pattern.
      It is worth mentioning the observed consequence of this bug: we were hitting the kernel
      BUG() in mm/bootmem.c:__free() that verifies when marking a page as free that it was
      previously marked as occupied (i.e that the bit was set to 1). The entire bootmem bitmap is
      set to 0xff bit via a memset() during the bootmem initialization. The bootmem_free() call right
      after the initialization was finding some bits to be set to 0, which didn't make sense since the
      bitmap has just been memset'ed to 0xff. Except that due to the bug explained above, the
      bitmap was in fact initialized to 0xff00ff00.
      Thanks to Marek Vasut for his help and feedback.
      Signed-off-by: default avatarRomain Perier <>
      Acked-by: default avatarMarek Vasut <>
      Acked-by: default avatarLey Foon Tan <>