1. 27 7月, 2011 3 次提交
  2. 28 6月, 2011 1 次提交
    • K
      Fix node_start/end_pfn() definition for mm/page_cgroup.c · c6830c22
      KAMEZAWA Hiroyuki 提交于
      commit 21a3c964 uses node_start/end_pfn(nid) for detection start/end
      of nodes. But, it's not defined in linux/mmzone.h but defined in
      /arch/???/include/mmzone.h which is included only under
      CONFIG_NEED_MULTIPLE_NODES=y.
      
      Then, we see
        mm/page_cgroup.c: In function 'page_cgroup_init':
        mm/page_cgroup.c:308: error: implicit declaration of function 'node_start_pfn'
        mm/page_cgroup.c:309: error: implicit declaration of function 'node_end_pfn'
      
      So, fixiing page_cgroup.c is an idea...
      
      But node_start_pfn()/node_end_pfn() is a very generic macro and
      should be implemented in the same manner for all archs.
      (m32r has different implementation...)
      
      This patch removes definitions of node_start/end_pfn() in each archs
      and defines a unified one in linux/mmzone.h. It's not under
      CONFIG_NEED_MULTIPLE_NODES, now.
      
      A result of macro expansion is here (mm/page_cgroup.c)
      
      for !NUMA
       start_pfn = ((&contig_page_data)->node_start_pfn);
        end_pfn = ({ pg_data_t *__pgdat = (&contig_page_data); __pgdat->node_start_pfn + __pgdat->node_spanned_pages;});
      
      for NUMA (x86-64)
        start_pfn = ((node_data[nid])->node_start_pfn);
        end_pfn = ({ pg_data_t *__pgdat = (node_data[nid]); __pgdat->node_start_pfn + __pgdat->node_spanned_pages;});
      
      Changelog:
       - fixed to avoid using "nid" twice in node_end_pfn() macro.
      Reported-and-acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Reported-and-tested-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c6830c22
  3. 27 5月, 2011 1 次提交
    • C
      arch/tile: more /proc and /sys file support · f133ecca
      Chris Metcalf 提交于
      This change introduces a few of the less controversial /proc and
      /proc/sys interfaces for tile, along with sysfs attributes for
      various things that were originally proposed as /proc/tile files.
      It also adjusts the "hardwall" proc API.
      
      Arnd Bergmann reviewed the initial arch/tile submission, which
      included a complete set of all the /proc/tile and /proc/sys/tile
      knobs that we had added in a somewhat ad hoc way during initial
      development, and provided feedback on where most of them should go.
      
      One knob turned out to be similar enough to the existing
      /proc/sys/debug/exception-trace that it was re-implemented to use
      that model instead.
      
      Another knob was /proc/tile/grid, which reported the "grid" dimensions
      of a tile chip (e.g. 8x8 processors = 64-core chip).  Arnd suggested
      looking at sysfs for that, so this change moves that information
      to a pair of sysfs attributes (chip_width and chip_height) in the
      /sys/devices/system/cpu directory.  We also put the "chip_serial"
      and "chip_revision" information from our old /proc/tile/board file
      as attributes in /sys/devices/system/cpu.
      
      Other information collected via hypervisor APIs is now placed in
      /sys/hypervisor.  We create a /sys/hypervisor/type file (holding the
      constant string "tilera") to be parallel with the Xen use of
      /sys/hypervisor/type holding "xen".  We create three top-level files,
      "version" (the hypervisor's own version), "config_version" (the
      version of the configuration file), and "hvconfig" (the contents of
      the configuration file).  The remaining information from our old
      /proc/tile/board and /proc/tile/switch files becomes an attribute
      group appearing under /sys/hypervisor/board/.
      
      Finally, after some feedback from Arnd Bergmann for the previous
      version of this patch, the /proc/tile/hardwall file is split up into
      two conceptual parts.  First, a directory /proc/tile/hardwall/ which
      contains one file per active hardwall, each file named after the
      hardwall's ID and holding a cpulist that says which cpus are enclosed by
      the hardwall.  Second, a /proc/PID file "hardwall" that is either
      empty (for non-hardwall-using processes) or contains the hardwall ID.
      
      Finally, this change pushes the /proc/sys/tile/unaligned_fixup/
      directory, with knobs controlling the kernel code for handling the
      fixup of unaligned exceptions.
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      f133ecca
  4. 20 5月, 2011 3 次提交
    • C
      arch/tile: cleanups for tilegx compat mode · 818d8462
      Chris Metcalf 提交于
      These changes make the syscall table line up correctly for
      tilegx compat mode, and remove the stale sys32_fadvise64() function,
      which isn't actually used by any syscall table.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      818d8462
    • C
      arch/tile: support signal "exception-trace" hook · 571d76ac
      Chris Metcalf 提交于
      This change adds support for /proc/sys/debug/exception-trace to tile.
      Like x86 and sparc, by default it is set to "1", generating a one-line
      printk whenever a user process crashes.  By setting it to "2", we get
      a much more complete userspace diagnostic at crash time, including
      a user-space backtrace, register dump, and memory dump around the
      address of the crash.
      
      Some vestiges of the Tilera-internal version of this support are
      removed with this patch (the show_crashinfo variable and the
      arch_coredump_signal function).  We retain a "crashinfo" boot parameter
      which allows you to set the boot-time value of exception-trace.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      571d76ac
    • C
      arch/tile: use better definitions of xchg() and cmpxchg() · 8aaf1dda
      Chris Metcalf 提交于
      These definitions use a ({}) construct to avoid some cases where
      we were getting warnings about unused return values.  We also
      promote the definition to the common <asm/atomic.h>, since it applies
      to both the 32- and 64-bit atomics.
      
      In addition, define __HAVE_ARCH_CMPXCHG for TILE-Gx since it has
      efficient direct atomic instructions.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      8aaf1dda
  5. 13 5月, 2011 1 次提交
    • C
      arch/tile: finish enabling support for TILE-Gx 64-bit chip · 18aecc2b
      Chris Metcalf 提交于
      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: NChris Metcalf <cmetcalf@tilera.com>
      Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [drivers/input]
      18aecc2b
  6. 05 5月, 2011 7 次提交
  7. 03 5月, 2011 2 次提交
    • C
      arch/tile: support TIF_NOTIFY_RESUME · 313ce674
      Chris Metcalf 提交于
      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: NChris Metcalf <cmetcalf@tilera.com>
      313ce674
    • C
      arch/tile: refactor backtracing code · 93013a0f
      Chris Metcalf 提交于
      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: NChris Metcalf <cmetcalf@tilera.com>
      93013a0f
  8. 24 3月, 2011 3 次提交
    • A
      bitops: remove minix bitops from asm/bitops.h · 61f2e7b0
      Akinobu Mita 提交于
      minix bit operations are only used by minix filesystem and useless by
      other modules.  Because byte order of inode and block bitmaps is different
      on each architecture like below:
      
      m68k:
      	big-endian 16bit indexed bitmaps
      
      h8300, microblaze, s390, sparc, m68knommu:
      	big-endian 32 or 64bit indexed bitmaps
      
      m32r, mips, sh, xtensa:
      	big-endian 32 or 64bit indexed bitmaps for big-endian mode
      	little-endian bitmaps for little-endian mode
      
      Others:
      	little-endian bitmaps
      
      In order to move minix bit operations from asm/bitops.h to architecture
      independent code in minix filesystem, this provides two config options.
      
      CONFIG_MINIX_FS_BIG_ENDIAN_16BIT_INDEXED is only selected by m68k.
      CONFIG_MINIX_FS_NATIVE_ENDIAN is selected by the architectures which use
      native byte order bitmaps (h8300, microblaze, s390, sparc, m68knommu,
      m32r, mips, sh, xtensa).  The architectures which always use little-endian
      bitmaps do not select these options.
      
      Finally, we can remove minix bit operations from asm/bitops.h for all
      architectures.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NGreg Ungerer <gerg@uclinux.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NPaul Mundt <lethal@linux-sh.org>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      61f2e7b0
    • A
      bitops: remove ext2 non-atomic bitops from asm/bitops.h · f312eff8
      Akinobu Mita 提交于
      As the result of conversions, there are no users of ext2 non-atomic bit
      operations except for ext2 filesystem itself.  Now we can put them into
      architecture independent code in ext2 filesystem, and remove from
      asm/bitops.h for all architectures.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f312eff8
    • A
      bitops: introduce little-endian bitops for most architectures · 861b5ae7
      Akinobu Mita 提交于
      Introduce little-endian bit operations to the big-endian architectures
      which do not have native little-endian bit operations and the
      little-endian architectures.  (alpha, avr32, blackfin, cris, frv, h8300,
      ia64, m32r, mips, mn10300, parisc, sh, sparc, tile, x86, xtensa)
      
      These architectures can just include generic implementation
      (asm-generic/bitops/le.h).
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NHans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
      Acked-by: N"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      861b5ae7
  9. 23 3月, 2011 1 次提交
  10. 18 3月, 2011 1 次提交
  11. 11 3月, 2011 6 次提交
    • M
      futex: Sanitize futex ops argument types · 8d7718aa
      Michel Lespinasse 提交于
      Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic
      prototypes to use u32 types for the futex as this is the data type the
      futex core code uses all over the place.
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Cc: Darren Hart <darren@dvhart.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20110311025058.GD26122@google.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      8d7718aa
    • M
      futex: Sanitize cmpxchg_futex_value_locked API · 37a9d912
      Michel Lespinasse 提交于
      The cmpxchg_futex_value_locked API was funny in that it returned either
      the original, user-exposed futex value OR an error code such as -EFAULT.
      This was confusing at best, and could be a source of livelocks in places
      that retry the cmpxchg_futex_value_locked after trying to fix the issue
      by running fault_in_user_writeable().
          
      This change makes the cmpxchg_futex_value_locked API more similar to the
      get_futex_value_locked one, returning an error code and updating the
      original value through a reference argument.
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Acked-by: Chris Metcalf <cmetcalf@tilera.com>  [tile]
      Acked-by: Tony Luck <tony.luck@intel.com>  [ia64]
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: Michal Simek <monstr@monstr.eu>  [microblaze]
      Acked-by: David Howells <dhowells@redhat.com> [frv]
      Cc: Darren Hart <darren@dvhart.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20110311024851.GC26122@google.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      37a9d912
    • C
      arch/tile: fix deadlock bugs in rwlock implementation · 3c5ead52
      Chris Metcalf 提交于
      The first issue fixed in this patch is that pending rwlock write locks
      could lock out new readers; this could cause a deadlock if a read lock was
      held on cpu 1, a write lock was then attempted on cpu 2 and was pending,
      and cpu 1 was interrupted and attempted to re-acquire a read lock.
      The write lock code was modified to not lock out new readers.
      
      The second issue fixed is that there was a narrow race window where a tns
      instruction had been issued (setting the lock value to "1") and the store
      instruction to reset the lock value correctly had not yet been issued.
      In this case, if an interrupt occurred and the same cpu then tried to
      manipulate the lock, it would find the lock value set to "1" and spin
      forever, assuming some other cpu was partway through updating it.  The fix
      is to enforce an interrupt critical section around the tns/store pair.
      
      In addition, this change now arranges to always validate that after
      a readlock we have not wrapped around the count of readers, which
      is only eight bits.
      
      Since these changes make the rwlock "fast path" code heavier weight,
      I decided to move all the rwlock code all out of line, leaving only the
      conventional spinlock code with fastpath inlines.  Since the read_lock
      and read_trylock implementations ended up very similar, I just expressed
      read_lock in terms of read_trylock.
      
      As part of this change I also eliminate support for the now-obsolete
      tns_atomic mode.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      3c5ead52
    • C
      drivers/edac: provide support for tile architecture · 5c770755
      Chris Metcalf 提交于
      Add tile support for the EDAC driver, which provides unified system
      error (memory, PCI, etc.) reporting. For now, the TILEPro port
      reports memory correctable error (CE) only.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      5c770755
    • C
      arch/tile: support 4KB page size as well as 64KB · 76c567fb
      Chris Metcalf 提交于
      The Tilera architecture traditionally supports 64KB page sizes
      to improve TLB utilization and improve performance when the
      hardware is being used primarily to run a single application.
      
      For more generic server scenarios, it can be beneficial to run
      with 4KB page sizes, so this commit allows that to be specified
      (by modifying the arch/tile/include/hv/pagesize.h header).
      
      As part of this change, we also re-worked the PTE management
      slightly so that PTE writes all go through a __set_pte() function
      where we can do some additional validation.  The set_pte_order()
      function was eliminated since the "order" argument wasn't being used.
      
      One bug uncovered was in the PCI DMA code, which wasn't properly
      flushing the specified range.  This was benign with 64KB pages,
      but with 4KB pages we were getting some larger flushes wrong.
      
      The per-cpu memory reservation code also needed updating to
      conform with the newer percpu stuff; before it always chose 64KB,
      and that was always correct, but with 4KB granularity we now have
      to pay closer attention and reserve the amount of memory that will
      be requested when the percpu code starts allocating.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      76c567fb
    • C
      arch/tile: fix some comments and whitespace · 5fb682b0
      Chris Metcalf 提交于
      This is a grab bag of changes with no actual change to generated code.
      This includes whitespace and comment typos, plus a couple of stale
      comments being removed.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      5fb682b0
  12. 02 3月, 2011 6 次提交
  13. 25 2月, 2011 1 次提交
  14. 18 12月, 2010 1 次提交
    • C
      arch/tile: handle rt_sigreturn() more cleanly · 81711cee
      Chris Metcalf 提交于
      The current tile rt_sigreturn() syscall pattern uses the common idiom
      of loading up pt_regs with all the saved registers from the time of
      the signal, then anticipating the fact that we will clobber the ABI
      "return value" register (r0) as we return from the syscall by setting
      the rt_sigreturn return value to whatever random value was in the pt_regs
      for r0.
      
      However, this breaks in our 64-bit kernel when running "compat" tasks,
      since we always sign-extend the "return value" register to properly
      handle returned pointers that are in the upper 2GB of the 32-bit compat
      address space.  Doing this to the sigreturn path then causes occasional
      random corruption of the 64-bit r0 register.
      
      Instead, we stop doing the crazy "load the return-value register"
      hack in sigreturn.  We already have some sigreturn-specific assembly
      code that we use to pass the pt_regs pointer to C code.  We extend that
      code to also set the link register to point to a spot a few instructions
      after the usual syscall return address so we don't clobber the saved r0.
      Now it no longer matters what the rt_sigreturn syscall returns, and the
      pt_regs structure can be cleanly and completely reloaded.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      81711cee
  15. 25 11月, 2010 2 次提交
    • C
      pci root complex: support for tile architecture · f02cbbe6
      Chris Metcalf 提交于
      This change enables PCI root complex support for TILEPro.  Unlike
      TILE-Gx, TILEPro has no support for memory-mapped I/O, so the PCI
      support consists of hypervisor upcalls for PIO, DMA, etc.  However,
      the performance is fine for the devices we have tested with so far
      (1Gb Ethernet, SATA, etc.).
      
      The <asm/io.h> header was tweaked to be a little bit more aggressive
      about disabling attempts to map/unmap IO port space.  The hacky
      <asm/pci-bridge.h> header was rolled into the <asm/pci.h> header
      and the result was simplified.  Both of the latter two headers were
      preliminary versions not meant for release before now - oh well.
      
      There is one quirk for our TILEmpower platform, which accidentally
      negotiates up to 5GT and needs to be kicked down to 2.5GT.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      f02cbbe6
    • C
      drivers/net/tile/: on-chip network drivers for the tile architecture · e5a06939
      Chris Metcalf 提交于
      This change adds the first network driver for the tile architecture,
      supporting the on-chip XGBE and GBE shims.
      
      The infrastructure is present for the TILE-Gx networking drivers (another
      three source files in the new directory) but for now the the actual
      tilegx sources are waiting on releasing hardware to initial customers.
      
      Note that arch/tile/include/hv/* are "upstream" headers from the
      Tilera hypervisor and will probably benefit less from LKML review.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      e5a06939
  16. 02 11月, 2010 1 次提交
    • C
      asm-generic/stat.h: support 64-bit file time_t for stat() · 2c7387ef
      Chris Metcalf 提交于
      The existing asm-generic/stat.h specifies st_mtime, etc., as a 32-value,
      and works well for 32-bit architectures (currently microblaze, score,
      and 32-bit tile).  However, for 64-bit architectures it isn't sufficient
      to return 32 bits of time_t; this isn't good insurance against the 2037
      rollover.  (It also makes glibc support less convenient, since we can't
      use glibc's handy STAT_IS_KERNEL_STAT mode.)
      
      This change extends the two "timespec" fields for each of the three atime,
      mtime, and ctime fields from "int" to "long".  As a result, on 32-bit
      platforms nothing changes, and 64-bit platforms will now work as expected.
      
      The only wrinkle is 32-bit userspace under 64-bit kernels taking advantage
      of COMPAT mode.  For these, we leave the "struct stat64" definitions with
      the "int" versions of the time_t and nsec fields, so that architectures
      can implement compat_sys_stat64() and friends with sys_stat64(), etc.,
      and get the expected 32-bit structure layout.  This requires a
      field-by-field copy in the kernel, implemented by the code guarded
      under __ARCH_WANT_STAT64.
      
      This does mean that the shape of the "struct stat" and "struct stat64"
      structures is different on a 64-bit kernel, but only one of the two
      structures should ever be used by any given process: "struct stat"
      is meant for 64-bit userspace only, and "struct stat64" for 32-bit
      userspace only.  (On a 32-bit kernel the two structures continue to have
      the same shape, since "long" is 32 bits.)
      
      The alternative is keeping the two structures the same shape on 64-bit
      kernels, which means a 64-bit time_t in "struct stat64" for 32-bit
      processes.  This is a little unnatural since 32-bit userspace can't
      do anything with 64 bits of time_t information, since time_t is just
      "long", not "int64_t"; and in any case 32-bit userspace might expect
      to be running under a 32-bit kernel, which can't provide the high 32
      bits anyway.  In the case of a 32-bit kernel we'd then be extending the
      kernel's 32-bit time_t to 64 bits, then truncating it back to 32 bits
      again in userspace, for no particular reason.  And, as mentioned above,
      if we have 64-bit time_t for 32-bit processes we can't easily use glibc's
      STAT_IS_KERNEL_STAT, since glibc's stat structure requires an embedded
      "struct timespec", which is a pair of "long" (32-bit) values in a 32-bit
      userspace.  "Inventive" solutions are possible, but are pretty hacky.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      2c7387ef