Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. Aug 22, 2014
  2. Aug 13, 2014
    • Dan Murphy's avatar
      Merge tag 'v3.14.17' of... · 367e55fb
      Dan Murphy authored
      Merge tag 'v3.14.17' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-3.14.y
      
      This is the 3.14.17 stable release
      
      * tag 'v3.14.17' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (40 commits)
        Linux 3.14.17
        xfs: log vector rounding leaks log space
        arch/sparc/math-emu/math_32.c: drop stray break operator
        sparc64: ldc_connect() should not return EINVAL when handshake is in progress.
        sunsab: Fix detection of BREAK on sunsab serial console
        bbc-i2c: Fix BBC I2C envctrl on SunBlade 2000
        sparc64: Guard against flushing openfirmware mappings.
        sparc64: Do not insert non-valid PTEs into the TSB hash table.
        sparc64: Add membar to Niagara2 memcpy code.
        sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.
        sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses.
        sparc64: Give more detailed information in {pgd,pmd}_ERROR() and kill pte_ERROR().
        sparc64: Add basic validations to {pud,pmd}_bad().
        sparc64: Us...
      367e55fb
    • Greg Kroah-Hartman's avatar
      Linux 3.14.17 · 946de0e6
      Greg Kroah-Hartman authored
      v3.14.17
      946de0e6
    • Dave Chinner's avatar
      xfs: log vector rounding leaks log space · 23647e98
      Dave Chinner authored
      commit 110dc24a
      
       upstream.
      
      The addition of direct formatting of log items into the CIL
      linear buffer added alignment restrictions that the start of each
      vector needed to be 64 bit aligned. Hence padding was added in
      xlog_finish_iovec() to round up the vector length to ensure the next
      vector started with the correct alignment.
      
      This adds a small number of bytes to the size of
      the linear buffer that is otherwise unused. The issue is that we
      then use the linear buffer size to determine the log space used by
      the log item, and this includes the unused space. Hence when we
      account for space used by the log item, it's more than is actually
      written into the iclogs, and hence we slowly leak this space.
      
      This results on log hangs when reserving space, with threads getting
      stuck with these stack traces:
      
      Call Trace:
      [<ffffffff81d15989>] schedule+0x29/0x70
      [<ffffffff8150d3a2>] xlog_grant_head_wait+0xa2/0x1a0
      [<ffffffff8150d55d>] xlog_grant_head_check+0xbd/0x140
      [<ffffffff8150ee33>] xfs_log_reserve+0x103/0x220
      [<ffffffff814b7f05>] xfs_trans_reserve+0x2f5/0x310
      .....
      
      The 4 bytes is significant. Brain Foster did all the hard work in
      tracking down a reproducable leak to inode chunk allocation (it went
      away with the ikeep mount option). His rough numbers were that
      creating 50,000 inodes leaked 11 log blocks. This turns out to be
      roughly 800 inode chunks or 1600 inode cluster buffers. That
      works out at roughly 4 bytes per cluster buffer logged, and at that
      I started looking for a 4 byte leak in the buffer logging code.
      
      What I found was that a struct xfs_buf_log_format structure for an
      inode cluster buffer is 28 bytes in length. This gets rounded up to
      32 bytes, but the vector length remains 28 bytes. Hence the CIL
      ticket reservation is decremented by 32 bytes (via lv->lv_buf_len)
      for that vector rather than 28 bytes which are written into the log.
      
      The fix for this problem is to separately track the bytes used by
      the log vectors in the item and use that instead of the buffer
      length when accounting for the log space that will be used by the
      formatted log item.
      
      Again, thanks to Brian Foster for doing all the hard work and long
      hours to isolate this leak and make finding the bug relatively
      simple.
      
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Cc: Bill <billstuff2001@sbcglobal.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23647e98
    • Andrey Utkin's avatar
      arch/sparc/math-emu/math_32.c: drop stray break operator · a7129df1
      Andrey Utkin authored
      [ Upstream commit 093758e3 ]
      
      This commit is a guesswork, but it seems to make sense to drop this
      break, as otherwise the following line is never executed and becomes
      dead code. And that following line actually saves the result of
      local calculation by the pointer given in function argument. So the
      proposed change makes sense if this code in the whole makes sense (but I
      am unable to analyze it in the whole).
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81641
      
      
      Reported-by: default avatarDavid Binderman <dcb314@hotmail.com>
      Signed-off-by: default avatarAndrey Utkin <andrey.krieger.utkin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7129df1
    • Sowmini Varadhan's avatar
      sparc64: ldc_connect() should not return EINVAL when handshake is in progress. · bb4c9762
      Sowmini Varadhan authored
      [ Upstream commit 4ec1b010
      
       ]
      
      The LDC handshake could have been asynchronously triggered
      after ldc_bind() enables the ldc_rx() receive interrupt-handler
      (and thus intercepts incoming control packets)
      and before vio_port_up() calls ldc_connect(). If that is the case,
      ldc_connect() should return 0 and let the state-machine
      progress.
      
      Signed-off-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Acked-by: default avatarKarl Volz <karl.volz@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb4c9762
    • Christopher Alexander Tobias Schulze's avatar
      sunsab: Fix detection of BREAK on sunsab serial console · f8cfa5d8
      Christopher Alexander Tobias Schulze authored
      [ Upstream commit fe418231
      
       ]
      
      Fix detection of BREAK on sunsab serial console: BREAK detection was only
      performed when there were also serial characters received simultaneously.
      To handle all BREAKs correctly, the check for BREAK and the corresponding
      call to uart_handle_break() must also be done if count == 0, therefore
      duplicate this code fragment and pull it out of the loop over the received
      characters.
      
      Patch applies to 3.16-rc6.
      
      Signed-off-by: default avatarChristopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8cfa5d8
    • Christopher Alexander Tobias Schulze's avatar
      bbc-i2c: Fix BBC I2C envctrl on SunBlade 2000 · eb191d89
      Christopher Alexander Tobias Schulze authored
      [ Upstream commit 5cdceab3
      
       ]
      
      Fix regression in bbc i2c temperature and fan control on some Sun systems
      that causes the driver to refuse to load due to the bbc_i2c_bussel resource not
      being present on the (second) i2c bus where the temperature sensors and fan
      control are located. (The check for the number of resources was removed when
      the driver was ported to a pure OF driver in mid 2008.)
      
      Signed-off-by: default avatarChristopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb191d89
    • David S. Miller's avatar
      sparc64: Guard against flushing openfirmware mappings. · 49e6ec05
      David S. Miller authored
      [ Upstream commit 4ca9a237 ]
      
      Based almost entirely upon a patch by Christopher Alexander Tobias
      Schulze.
      
      In commit db64fe02 ("mm: rewrite vmap
      layer") lazy VMAP tlb flushing was added to the vmalloc layer.  This
      causes problems on sparc64.
      
      Sparc64 has two VMAP mapped regions and they are not contiguous with
      eachother.  First we have the malloc mapping area, then another
      unrelated region, then the vmalloc region.
      
      This "another unrelated region" is where the firmware is mapped.
      
      If the lazy TLB flushing logic in the vmalloc code triggers after
      we've had both a module unload and a vfree or similar, it will pass an
      address range that goes from somewhere inside the malloc region to
      somewhere inside the vmalloc region, and thus covering the
      openfirmware area entirely.
      
      The sparc64 kernel learns about openfirmware's dynamic mappings in
      this region early in the boot, and then services TLB mis...
      49e6ec05
    • David S. Miller's avatar
      sparc64: Do not insert non-valid PTEs into the TSB hash table. · b4a8febe
      David S. Miller authored
      [ Upstream commit 18f38132
      
       ]
      
      The assumption was that update_mmu_cache() (and the equivalent for PMDs) would
      only be called when the PTE being installed will be accessible by the user.
      
      This is not true for code paths originating from remove_migration_pte().
      
      There are dire consequences for placing a non-valid PTE into the TSB.  The TLB
      miss frramework assumes thatwhen a TSB entry matches we can just load it into
      the TLB and return from the TLB miss trap.
      
      So if a non-valid PTE is in there, we will deadlock taking the TLB miss over
      and over, never satisfying the miss.
      
      Just exit early from update_mmu_cache() and friends in this situation.
      
      Based upon a report and patch from Christopher Alexander Tobias Schulze.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4a8febe
    • David S. Miller's avatar
      sparc64: Add membar to Niagara2 memcpy code. · a8973758
      David S. Miller authored
      [ Upstream commit 5aa4ecfd
      
       ]
      
      This is the prevent previous stores from overlapping the block stores
      done by the memcpy loop.
      
      Based upon a glibc patch by Jose E. Marchesi
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8973758
    • David S. Miller's avatar
      sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus. · c184f95b
      David S. Miller authored
      [ Upstream commit b18eb2d7
      
       ]
      
      Access to the TSB hash tables during TLB misses requires that there be
      an atomic 128-bit quad load available so that we fetch a matching TAG
      and DATA field at the same time.
      
      On cpus prior to UltraSPARC-III only virtual address based quad loads
      are available.  UltraSPARC-III and later provide physical address
      based variants which are easier to use.
      
      When we only have virtual address based quad loads available this
      means that we have to lock the TSB into the TLB at a fixed virtual
      address on each cpu when it runs that process.  We can't just access
      the PAGE_OFFSET based aliased mapping of these TSBs because we cannot
      take a recursive TLB miss inside of the TLB miss handler without
      risking running out of hardware trap levels (some trap combinations
      can be deep, such as those generated by register window spill and fill
      traps).
      
      Without huge pages it's working perfectly fine, but when the huge TSB
      got added another chunk of fixed virtual address space was not
      allocated for this second TSB mapping.
      
      So we were mapping both the 8K and 4MB TSBs to the same exact virtual
      address, causing multiple TLB matches which gives undefined behavior.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c184f95b
    • David S. Miller's avatar
      sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses. · 8f0a3c34
      David S. Miller authored
      [ Upstream commit e5c460f4
      
       ]
      
      This was found using Dave Jone's trinity tool.
      
      When a user process which is 32-bit performs a load or a store, the
      cpu chops off the top 32-bits of the effective address before
      translating it.
      
      This is because we run 32-bit tasks with the PSTATE_AM (address
      masking) bit set.
      
      We can't run the kernel with that bit set, so when the kernel accesses
      userspace no address masking occurs.
      
      Since a 32-bit process will have no mappings in that region we will
      properly fault, so we don't try to handle this using access_ok(),
      which can safely just be a NOP on sparc64.
      
      Real faults from 32-bit processes should never generate such addresses
      so a bug check was added long ago, and it barks in the logs if this
      happens.
      
      But it also barks when a kernel user access causes this condition, and
      that _can_ happen.  For example, if a pointer passed into a system call
      is "0xfffffffc" and the kernel access 4 bytes offset from that pointer.
      
      Just handle such faults normally via the exception entries.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f0a3c34
    • David S. Miller's avatar
      sparc64: Give more detailed information in {pgd,pmd}_ERROR() and kill pte_ERROR(). · 89e69c2e
      David S. Miller authored
      [ Upstream commit fe866433
      
       ]
      
      pte_ERROR() is not used anywhere, delete it.
      
      For pgd_ERROR() and pmd_ERROR(), output something similar to x86, giving the address
      of the pgd/pmd as well as it's value.
      
      Also provide the caller, since these macros are invoked from pgd_clear_bad() and
      pmd_clear_bad() which provides little context as to what high level operation was
      occuring when the BAD state was detected.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89e69c2e
    • David S. Miller's avatar
      sparc64: Add basic validations to {pud,pmd}_bad(). · e4f2eef2
      David S. Miller authored
      [ Upstream commit 26cf4325
      
       ]
      
      Instead of returning false we should at least check the most basic
      things, otherwise page table corruptions will be very difficult to
      debug.
      
      PMD and PTE tables are of size PAGE_SIZE, so none of the sub-PAGE_SIZE
      bits should be set.
      
      We also complement this with a check that the physical address the
      pud/pmd points to is valid memory.
      
      PowerPC was used as a guide while implementating this.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4f2eef2