1. 31 Oct, 2015 1 commit
    • Linus Torvalds's avatar
      vfs: Fix pathological performance case for __alloc_fd() · f3f86e33
      Linus Torvalds authored
      Al Viro points out that:
      > >     * [Linux-specific aside] our __alloc_fd() can degrade quite badly
      > > with some use patterns.  The cacheline pingpong in the bitmap is probably
      > > inevitable, unless we accept considerably heavier memory footprint,
      > > but we also have a case when alloc_fd() takes O(n) and it's _not_ hard
      > > to trigger - close(3);open(...); will have the next open() after that
      > > scanning the entire in-use bitmap.
      
      And Eric Dumazet has a somewhat realistic multithreaded microbenchmark
      that opens and closes a lot of sockets with minimal work per socket.
      
      This patch largely fixes it.  We keep a 2nd-level bitmap of the open
      file bitmaps, showing which words are already full.  So then we can
      traverse that second-level bitmap to efficiently skip already allocated
      file descriptors.
      
      On his benchmark, this improves performance by up to an order of
      magnitude, by avoiding the excessive open file bitmap scanning.
      Tested-and-acked-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f3f86e33
  2. 28 Oct, 2015 3 commits
  3. 27 Oct, 2015 5 commits
  4. 26 Oct, 2015 4 commits
    • Linus Torvalds's avatar
      Merge tag 'iommu-fixes-v4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · 858e904b
      Linus Torvalds authored
      Pull iommu fixes from Joerg Roedel:
       "Two late fixes for the AMD IOMMU driver:
      
         - add an additional check to the io page-fault handler to avoid a
           BUG_ON being hit in handle_mm_fault()
      
         - fix a problem with devices writing to the system management area
           and were blocked by the IOMMU because the driver wrongly cleared
           out the DTE flags allowing that access"
      
      * tag 'iommu-fixes-v4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu/amd: Don't clear DTE flags when modifying it
        iommu/amd: Fix BUG when faulting a PROT_NONE VMA
      858e904b
    • Linus Torvalds's avatar
      Merge tag 'md/4.3-rc6-fixes' of git://neil.brown.name/md · ce6f9886
      Linus Torvalds authored
      Pull md fixes from Neil Brown:
       "Some raid1/raid10 fixes.
      
        I meant to get this to you before -rc7, but what with all the travel
        plans..
      
        Two fixes for bugs that are in both raid1 and raid10.  Both related to
        bad-block-lists and at least one needs to be back ported to 3.1.
      
        Also a revision for the "new" layout in raid10.  This "new" code
        (which aims to improve robustness) actually reduces robustness in some
        cases.  It probably isn't in use at all as not public user-space code
        makes use of these new layouts.  However just in case someone has
        their own code, it would be good to get the WARNing out for them
        sooner"
      
      * tag 'md/4.3-rc6-fixes' of git://neil.brown.name/md:
        md/raid10: fix the 'new' raid10 layout to work correctly.
        md/raid10: don't clear bitmap bit when bad-block-list write fails.
        md/raid1: don't clear bitmap bit when bad-block-list write fails.
        md/raid10: submit_bio_wait() returns 0 on success
        md/raid1: submit_bio_wait() returns 0 on success
      ce6f9886
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 896066ee
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Last fixes from me: one amdgpu/radeon suspend resume and one leak fix,
        along with one vmware fix for some issues when command submission
        fails"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/amdgpu: don't try to recreate sysfs entries on resume
        drm/radeon: don't try to recreate sysfs entries on resume
        drm/amdgpu: stop leaking page flip fence
        drm/vmwgfx: Stabilize the command buffer submission code
      896066ee
    • Linus Torvalds's avatar
      Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · 85051e29
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "Two driver bugfixes for the I2C subsystem"
      
      * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        i2c: pnx: fix runtime warnings caused by enabling unprepared clock
        i2c: mv64xxx: really allow I2C offloading
      85051e29
  5. 25 Oct, 2015 1 commit
  6. 24 Oct, 2015 5 commits
    • Dave Airlie's avatar
      Merge branch 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux · 22ca7ca5
      Dave Airlie authored
      I'm not sure whether this patch comes in too late, but it would be good to
      have it in. It stabilizes command submission in case of command buffer errors.
      
      * 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux:
        drm/vmwgfx: Stabilize the command buffer submission code
      22ca7ca5
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux · aef8cc90
      Dave Airlie authored
      Two regression fixes and a memory leak fix for amdgpu and radeon.
      
      * 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
        drm/amdgpu: don't try to recreate sysfs entries on resume
        drm/radeon: don't try to recreate sysfs entries on resume
        drm/amdgpu: stop leaking page flip fence
      aef8cc90
    • NeilBrown's avatar
      md/raid10: fix the 'new' raid10 layout to work correctly. · 8bce6d35
      NeilBrown authored
      In Linux 3.9 we introduce a new 'far' layout for RAID10 which was
      supposed to rotate the replicas differently and so provide better
      resilience.  In particular it could survive more combinations of 2
      drive failures.
      
      Unfortunately. due to a coding error, this some did what was wanted,
      sometimes improved less than we hoped, and sometimes - in very
      unlikely circumstances - put multiple replicas on the same device so
      the redundancy was harmed.
      
      No public user-space tool has created arrays using this layout so it
      is very unlikely that zero-redundancy arrays actually exist.  Probably
      no arrays using any form of the new layout exist.  But we cannot be
      certain.
      
      So use another bit in the 'layout' number and introduce a bug-fixed
      version of the layout.
      Also when assembling an array, if it has a zero-redundancy layout,
      give a warning.
      Reported-by: default avatarHeinz Mauelshagen <heinzm@redhat.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      8bce6d35
    • NeilBrown's avatar
      md/raid10: don't clear bitmap bit when bad-block-list write fails. · c340702c
      NeilBrown authored
      When a write fails and a bad-block-list is present, we can
      update the bad-block-list instead of writing the data.  If
      this succeeds then it is OK clear the relevant bitmap-bit as
      no further 'sync' of the block is needed.
      
      However if writing the bad-block-list fails then we need to
      treat the write as failed and particularly must not clear
      the bitmap bit.  Otherwise the device can be re-added (after
      any hardware connection issues are resolved) and because the
      relevant bit in the bitmap is clear, that block will not be
      resynced.  This leads to data corruption.
      
      We already delay the final bio_endio() on the write until
      the bad-block-list is written so that when the write
      returns: either that data is safe, the bad-block record is
      safe, or the fact that the device is faulty is safe.
      However we *don't* delay the clearing of the bitmap, so the
      bitmap bit can be recorded as cleared before we know if the
      bad-block-list was written safely.
      
      So: delay that until the write really is safe.
      i.e. move the call to close_write() until just before
      calling bio_endio(), and recheck the 'is array degraded'
      status before making that call.
      
      This bug goes back to v3.1 when bad-block-lists were
      introduced, though it only affects arrays created with
      mdadm-3.3 or later as only those have bad-block lists.
      
      Backports will require at least
      Commit: 95af587e ("md/raid10: ensure device failure recorded before write request returns.")
      as well.  I'll send that to 'stable' separately.
      
      Note that of the two tests of R10BIO_WriteError that this
      patch adds, the first is certain to fail and the second is
      certain to succeed.  However doing it this way makes the
      patch more obviously correct.  I will tidy the code up in a
      future merge window.
      Reported-by: default avatarNate Dailey <nate.dailey@stratus.com>
      Fixes: bd870a16 ("md/raid10:  Handle write errors by updating badblock log.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      c340702c
    • NeilBrown's avatar
      md/raid1: don't clear bitmap bit when bad-block-list write fails. · bd8688a1
      NeilBrown authored
      When a write fails and a bad-block-list is present, we can
      update the bad-block-list instead of writing the data.  If
      this succeeds then it is OK clear the relevant bitmap-bit as
      no further 'sync' of the block is needed.
      
      However if writing the bad-block-list fails then we need to
      treat the write as failed and particularly must not clear
      the bitmap bit.  Otherwise the device can be re-added (after
      any hardware connection issues are resolved) and because the
      relevant bit in the bitmap is clear, that block will not be
      resynced.  This leads to data corruption.
      
      We already delay the final bio_endio() on the write until
      the bad-block-list is written so that when the write
      returns: either that data is safe, the bad-block record is
      safe, or the fact that the device is faulty is safe.
      However we *don't* delay the clearing of the bitmap, so the
      bitmap bit can be recorded as cleared before we know if the
      bad-block-list was written safely.
      
      So: delay that until the write really is safe.
      i.e. move the call to close_write() until just before
      calling bio_endio(), and recheck the 'is array degraded'
      status before making that call.
      
      This bug goes back to v3.1 when bad-block-lists were
      introduced, though it only affects arrays created with
      mdadm-3.3 or later as only those have bad-block lists.
      
      Backports will require at least
      Commit: 55ce74d4 ("md/raid1: ensure device failure recorded before write request returns.")
      as well.  I'll send that to 'stable' separately.
      
      Note that of the two tests of R1BIO_WriteError that this
      patch adds, the first is certain to fail and the second is
      certain to succeed.  However doing it this way makes the
      patch more obviously correct.  I will tidy the code up in a
      future merge window.
      Reported-and-tested-by: default avatarNate Dailey <nate.dailey@stratus.com>
      Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
      Fixes: cd5ff9a1 ("md/raid1:  Handle write errors by updating badblock log.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      bd8688a1
  7. 23 Oct, 2015 21 commits