1. 20 May, 2011 2 commits
  2. 17 May, 2011 1 commit
  3. 12 May, 2011 2 commits
    • Chris Metcalf's avatar
      arch/tile: finish enabling support for TILE-Gx 64-bit chip · 18aecc2b
      Chris Metcalf authored
      
      
      This support was partially present in the existing code (look for
      "__tilegx__" ifdefs) but with this change you can build a working
      kernel using the TILE-Gx toolchain and ARCH=tilegx.
      
      Most of these files are new, generally adding a foo_64.c file
      where previously there was just a foo_32.c file.
      
      The ARCH=tilegx directive redirects to arch/tile, not arch/tilegx,
      using the existing SRCARCH mechanism in the top-level Makefile.
      
      Changes to existing files:
      
      - <asm/bitops.h> and <asm/bitops_32.h> changed to factor the
        include of <asm-generic/bitops/non-atomic.h> in the common header.
      
      - <asm/compat.h> and arch/tile/kernel/compat.c changed to remove
        the "const" markers I had put on compat_sys_execve() when trying
        to match some recent similar changes to the non-compat execve.
        It turns out the compat version wasn't "upgraded" to use const.
      
      - <asm/opcode-tile_64.h> and <asm/opcode_constants_64.h> were
        previously included accidentally, with the 32-bit contents.  Now
        they have the proper 64-bit contents.
      
      Finally, I had to hack the existing hacky drivers/input/input-compat.h
      to add yet another "#ifdef" for INPUT_COMPAT_TEST (same as x86_64).
      
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [drivers/input]
      18aecc2b
    • Chris Metcalf's avatar
      compat: fixes to allow working with tile arch · be84cb43
      Chris Metcalf authored
      
      
      The existing <asm-generic/unistd.h> mechanism doesn't really provide
      enough to create the 64-bit "compat" ABI properly in a generic way,
      since the compat ABI is a mix of things were you can re-use the 64-bit
      versions of syscalls and things where you need a compat wrapper.
      
      To provide this in the most direct way possible, I added two new macros
      to go along with the existing __SYSCALL and __SC_3264 macros: __SC_COMP
      and SC_COMP_3264.  These macros take an additional argument, typically a
      "compat_sys_xxx" function, which is passed to __SYSCALL if you define
      __SYSCALL_COMPAT when including the header, resulting in a pointer to
      the compat function being placed in the generated syscall table.
      
      The change also adds some missing definitions to <linux/compat.h> so that
      it actually has declarations for all the compat syscalls, since the
      "[nr] = ##call" approach requires proper C declarations for all the
      functions included in the syscall table.
      
      Finally, compat.c defines compat_sys_sigpending() and
      compat_sys_sigprocmask() even if the underlying architecture doesn't
      request it, which tries to pull in undefined compat_old_sigset_t defines.
      We need to guard those compat syscall definitions with appropriate
      __ARCH_WANT_SYS_xxx ifdefs.
      
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      be84cb43
  4. 04 May, 2011 14 commits
  5. 02 May, 2011 2 commits
    • Chris Metcalf's avatar
      arch/tile: support TIF_NOTIFY_RESUME · 313ce674
      Chris Metcalf authored
      
      
      This support is required for CONFIG_KEYS, NFSv4 kernel DNS, etc.
      The change is slightly more complex than the minimal thing, since
      I took advantage of having to go into the assembly code to just
      move a bunch of stuff into C code: specifically, the schedule(),
      do_async_page_fault(), do_signal(), and single_step_once() support,
      in addition to the TIF_NOTIFY_RESUME support.
      
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      313ce674
    • Chris Metcalf's avatar
      arch/tile: refactor backtracing code · 93013a0f
      Chris Metcalf authored
      
      
      This change is the result of some work to make the backtrace code more
      shareable between kernel, libc, and gdb.
      
      For the kernel, some good effects are to eliminate the hacky
      "VirtualAddress" typedef in favor of "unsigned long", to eliminate a
      bunch of spurious kernel doc comments, to remove the dead "bt_read_memory"
      function, and to use "__tilegx__" in #ifdefs instead of "TILE_CHIP".
      
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      93013a0f
  6. 27 Apr, 2011 2 commits
  7. 26 Apr, 2011 15 commits
  8. 25 Apr, 2011 2 commits
    • Tyler Hicks's avatar
      eCryptfs: Flush dirty pages in setattr · 5be79de2
      Tyler Hicks authored
      After 57db4e8d changed eCryptfs to
      write-back caching, eCryptfs page writeback updates the lower inode
      times due to the use of vfs_write() on the lower file.
      
      To preserve inode metadata changes, such as 'cp -p' does with
      utimensat(), we need to flush all dirty pages early in
      ecryptfs_setattr() so that the user-updated lower inode metadata isn't
      clobbered later in writeback.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=33372
      
      
      
      Reported-by: default avatarRocko <rockorequin@hotmail.com>
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      5be79de2
    • Tyler Hicks's avatar
      eCryptfs: Handle failed metadata read in lookup · 3aeb86ea
      Tyler Hicks authored
      When failing to read the lower file's crypto metadata during a lookup,
      eCryptfs must continue on without throwing an error. For example, there
      may be a plaintext file in the lower mount point that the user wants to
      delete through the eCryptfs mount.
      
      If an error is encountered while reading the metadata in lookup(), the
      eCryptfs inode's size could be incorrect. We must be sure to reread the
      plaintext inode size from the metadata when performing an open() or
      setattr(). The metadata is already being read in those paths, so this
      adds minimal performance overhead.
      
      This patch introduces a flag which will track whether or not the
      plaintext inode size has been read so that an incorrect i_size can be
      fixed in the open() or setattr() paths.
      
      https://bugs.launchpad.net/bugs/509180
      
      
      
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarTyler Hicks <tyhicks@linux.vnet.ibm.com>
      3aeb86ea