1. 17 May, 2014 1 commit
  2. 08 May, 2014 1 commit
    • David S. Miller's avatar
      sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus. · b18eb2d7
      David S. Miller authored
      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>
      b18eb2d7
  3. 07 May, 2014 1 commit
    • David S. Miller's avatar
      sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses. · e5c460f4
      David S. Miller authored
      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>
      e5c460f4
  4. 06 May, 2014 4 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse · 256cf4c4
      Linus Torvalds authored
      Pull fuse fixes from Miklos Szeredi:
       "This adds ctime update in the new cached writeback mode and also
        fixes/simplifies the mtime update handling.  Support for rename flags
        (aka renameat2) is also added to the userspace API"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
        fuse: add renameat2 support
        fuse: clear MS_I_VERSION
        fuse: clear FUSE_I_CTIME_DIRTY flag on setattr
        fuse: trust kernel i_ctime only
        fuse: remove .update_time
        fuse: allow ctime flushing to userspace
        fuse: fuse: add time_gran to INIT_OUT
        fuse: add .write_inode
        fuse: clean up fsync
        fuse: fuse: fallocate: use file_update_time()
        fuse: update mtime on open(O_TRUNC) in atomic_o_trunc mode
        fuse: update mtime on truncate(2)
        fuse: do not use uninitialized i_mode
        fuse: fix mtime update error in fsync
        fuse: check fallocate mode
        fuse: add __exit to fuse_ctl_cleanup
      256cf4c4
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc · 9bd29c56
      Linus Torvalds authored
      Pull sparc fixes from David Miller:
       "I've been auditing the THP support on sparc64 and found several bugs,
        hopefully most of which are fixed completely here.
      
        Also an RT kernel locking fix from Kirill Tkhai"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
        sparc64: Give more detailed information in {pgd,pmd}_ERROR() and kill pte_ERROR().
        sparc64: Add basic validations to {pud,pmd}_bad().
        sparc64: Use 'ILOG2_4MB' instead of constant '22'.
        sparc64: Fix range check in kern_addr_valid().
        sparc64: Fix top-level fault handling bugs.
        sparc64: Handle 32-bit tasks properly in compute_effective_address().
        sparc64: Don't use _PAGE_PRESENT in pte_modify() mask.
        sparc64: Fix hex values in comment above pte_modify().
        sparc64: Fix bugs in get_user_pages_fast() wrt. THP.
        sparc64: Fix huge PMD invalidation.
        sparc64: Fix executable bit testing in set_pmd_at() paths.
        sparc64: Normalize NMI watchdog logging and behavior.
        sparc64: Make itc_sync_lock raw
        sparc64: Fix argument sign extension for compat_sys_futex().
      9bd29c56
    • David Miller's avatar
      slab: Fix off by one in object max number tests. · 30321c7b
      David Miller authored
      If freelist_idx_t is a byte, SLAB_OBJ_MAX_NUM should be 255 not 256, and
      likewise if freelist_idx_t is a short, then it should be 65535 not
      65536.
      
      This was leading to all kinds of random crashes on sparc64 where
      PAGE_SIZE is 8192.  One problem shown was that if spinlock debugging was
      enabled, we'd get deadlocks in copy_pte_range() or do_wp_page() with the
      same cpu already holding a lock it shouldn't hold, or the lock belonging
      to a completely unrelated process.
      
      Fixes: a41adfaa ("slab: introduce byte sized index for the freelist of a slab")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      30321c7b
    • Joonsoo Kim's avatar
      slab: fix the type of the index on freelist index accessor · 7cc68973
      Joonsoo Kim authored
      Commit a41adfaa ("slab: introduce byte sized index for the freelist
      of a slab") changes the size of freelist index and also changes
      prototype of accessor function to freelist index.  And there was a
      mistake.
      
      The mistake is that although it changes the size of freelist index
      correctly, it changes the size of the index of freelist index
      incorrectly.  With patch, freelist index can be 1 byte or 2 bytes, that
      means that num of object on on a slab can be more than 255.  So we need
      more than 1 byte for the index to find the index of free object on
      freelist.  But, above patch makes this index type 1 byte, so slab which
      have more than 255 objects cannot work properly and in consequence of
      it, the system cannot boot.
      
      This issue was reported by Steven King on m68knommu which would use
      2 bytes freelist index:
      
        https://lkml.org/lkml/2014/4/16/433
      
      To fix is easy.  To change the type of the index of freelist index on
      accessor functions is enough to fix this bug.  Although 2 bytes is
      enough, I use 4 bytes since it have no bad effect and make things more
      easier.  This fix was suggested and tested by Steven in his original
      report.
      Signed-off-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Reported-and-acked-by: default avatarSteven King <sfking@fdwdc.com>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Tested-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Tested-by: default avatarDavid Miller <davem@davemloft.net>
      Cc: Pekka Enberg <penberg@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7cc68973
  5. 05 May, 2014 33 commits