1. 10 Apr, 2012 1 commit
  2. 03 Jan, 2012 1 commit
  3. 11 Dec, 2011 1 commit
  4. 28 Sep, 2011 1 commit
    • Paul E. McKenney's avatar
      rcu: Move rcu_head definition to types.h · 99098751
      Paul E. McKenney authored
      
      
      Take a first step towards untangling Linux kernel header files by
      placing the struct rcu_head definition into include/linux/types.h
      and including include/linux/types.h in include/linux/rcupdate.h
      where struct rcu_head used to be defined.  The actual inclusion point
      for include/linux/types.h is with the rest of the #include directives
      rather than at the point where struct rcu_head used to be defined,
      as suggested by Mathieu Desnoyers.
      
      Once this is in place, then header files that need only rcu_head
      can include types.h rather than rcupdate.h.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      99098751
  5. 22 Mar, 2011 1 commit
  6. 26 Oct, 2010 1 commit
  7. 15 Oct, 2010 1 commit
  8. 11 Jul, 2010 1 commit
  9. 06 Jul, 2010 1 commit
    • Chris Metcalf's avatar
      Move list types from <linux/list.h> to <linux/types.h>. · de5d9bf6
      Chris Metcalf authored
      
      
      This allows a list_head (or hlist_head, etc.) to be used from places
      that used to be impractical, in particular <asm/processor.h>, which
      used to cause include file recursion: <linux/list.h> includes
      <linux/prefetch.h>, which always includes <asm/processor.h> for the
      prefetch macros, as well as <asm/system.h>, which often includes
      <asm/processor.h> directly or indirectly.
      
      This avoids a lot of painful workaround hackery on the tile
      architecture, where we use a list_head in the thread_struct to chain
      together tasks that are activated on a particular hardwall.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Reviewed-by: default avatarMatthew Wilcox <willy@linux.intel.com>
      de5d9bf6
  10. 17 May, 2010 1 commit
    • Anton Blanchard's avatar
      atomic_t: Remove volatile from atomic_t definition · 81880d60
      Anton Blanchard authored
      When looking at a performance problem on PowerPC, I noticed some awful code
      generation:
      
      c00000000051fc98:       3b 60 00 01     li      r27,1
      ...
      c00000000051fca0:       3b 80 00 00     li      r28,0
      ...
      c00000000051fcdc:       93 61 00 70     stw     r27,112(r1)
      c00000000051fce0:       93 81 00 74     stw     r28,116(r1)
      c00000000051fce4:       81 21 00 70     lwz     r9,112(r1)
      c00000000051fce8:       80 01 00 74     lwz     r0,116(r1)
      c00000000051fcec:       7d 29 07 b4     extsw   r9,r9
      c00000000051fcf0:       7c 00 07 b4     extsw   r0,r0
      
      c00000000051fcf4:       7c 20 04 ac     lwsync
      c00000000051fcf8:       7d 60 f8 28     lwarx   r11,0,r31
      c00000000051fcfc:       7c 0b 48 00     cmpw    r11,r9
      c00000000051fd00:       40 c2 00 10     bne-    c00000000051fd10
      c00000000051fd04:       7c 00 f9 2d     stwcx.  r0,0,r31
      c00000000051fd08:       40 c2 ff f0     bne+    c00000000051fcf8
      c00000000051fd0c:       4c 00 01 2c     isync
      
      We create two constants, write them out to the stack, read them straight back
      in and sign extend them. What a mess.
      
      It turns out this bad code is a result of us defining atomic_t as a
      volatile int.
      
      We removed the volatile attribute from the powerpc atomic_t definition years
      ago, but commit ea435467
      
       (atomic_t: unify all
      arch definitions) added it back in.
      
      To dig up an old quote from Linus:
      
      > The fact is, volatile on data structures is a bug. It's a wart in the C
      > language. It shouldn't be used.
      >
      > Volatile accesses in *code* can be ok, and if we have "atomic_read()"
      > expand to a "*(volatile int *)&(x)->value", then I'd be ok with that.
      >
      > But marking data structures volatile just makes the compiler screw up
      > totally, and makes code for initialization sequences etc much worse.
      
      And screw up it does :)
      
      With the volatile removed, we see much more reasonable code generation:
      
      c00000000051f5b8:       3b 60 00 01     li      r27,1
      ...
      c00000000051f5c0:       3b 80 00 00     li      r28,0
      ...
      
      c00000000051fc7c:       7c 20 04 ac     lwsync
      c00000000051fc80:       7c 00 f8 28     lwarx   r0,0,r31
      c00000000051fc84:       7c 00 d8 00     cmpw    r0,r27
      c00000000051fc88:       40 c2 00 10     bne-    c00000000051fc98
      c00000000051fc8c:       7f 80 f9 2d     stwcx.  r28,0,r31
      c00000000051fc90:       40 c2 ff f0     bne+    c00000000051fc80
      c00000000051fc94:       4c 00 01 2c     isync
      
      Six instructions less.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      81880d60
  11. 19 Jun, 2009 1 commit
  12. 26 Mar, 2009 2 commits
  13. 07 Feb, 2009 1 commit
  14. 06 Feb, 2009 1 commit
  15. 07 Jan, 2009 1 commit
  16. 06 Jan, 2009 1 commit
  17. 29 Dec, 2008 1 commit
    • Jens Axboe's avatar
      Get rid of CONFIG_LSF · b3a6ffe1
      Jens Axboe authored
      
      
      We have two seperate config entries for large devices/files. One
      is CONFIG_LBD that guards just the devices, the other is CONFIG_LSF
      that handles large files. This doesn't make a lot of sense, you typically
      want both or none. So get rid of CONFIG_LSF and change CONFIG_LBD wording
      to indicate that it covers both.
      Acked-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      b3a6ffe1
  18. 21 Oct, 2008 1 commit
  19. 14 Sep, 2008 2 commits
  20. 24 May, 2008 1 commit
  21. 08 Feb, 2008 1 commit
  22. 31 Jan, 2008 1 commit
  23. 29 Oct, 2007 1 commit
    • Al Viro's avatar
      fix abuses of ptrdiff_t · 142956af
      Al Viro authored
      
      
      Use of ptrdiff_t in places like
      
      -                       if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf, u_tmp->len))
      +                       if (!access_ok(VERIFY_WRITE, (u8 __user *)
      +                                               (ptrdiff_t) u_tmp->rx_buf,
      +                                               u_tmp->len))
      
      is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general
      we are not even promised that ptrdiff_t is large enough to hold a pointer,
      just enough to hold a difference between two pointers within the same object).
      For another, it confuses the fsck out of sparse.
      
      Use unsigned long or uintptr_t instead.  There are several places misusing
      ptrdiff_t; fixed.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      142956af
  24. 19 Oct, 2007 1 commit
  25. 04 Dec, 2006 1 commit
    • Matthew Wilcox's avatar
      [PATCH] Centralise definitions of sector_t and blkcnt_t · e6243863
      Matthew Wilcox authored
      
      
      CONFIG_LBD and CONFIG_LSF are spread into asm/types.h for no particularly
      good reason.
      
      Centralising the definition in linux/types.h means that arch maintainers
      don't need to bother adding it, as well as fixing the problem with
      x86-64 users being asked to make a decision that has absolutely no
      effect.
      
      The H8/300 porters seem particularly confused since I'm not aware of any
      microcontrollers that need to support 2TB filesystems.
      Signed-off-by: default avatarMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e6243863
  26. 02 Dec, 2006 2 commits
  27. 04 Oct, 2006 1 commit
  28. 01 Oct, 2006 1 commit
  29. 27 Jun, 2006 2 commits
  30. 26 Apr, 2006 1 commit
  31. 26 Mar, 2006 1 commit
    • Takashi Sato's avatar
      [PATCH] 2TB files: add blkcnt_t · a0f62ac6
      Takashi Sato authored
      
      
      Add blkcnt_t as the type of inode.i_blocks.  This enables you to make the size
      of blkcnt_t either 4 bytes or 8 bytes on 32 bits architecture with CONFIG_LSF.
      
      - CONFIG_LSF
        Add new configuration parameter.
      - blkcnt_t
        On h8300, i386, mips, powerpc, s390 and sh that define sector_t,
        blkcnt_t is defined as u64 if CONFIG_LSF is enabled; otherwise it is
        defined as unsigned long.
        On other architectures, it is defined as unsigned long.
      - inode.i_blocks
        Change the type from sector_t to blkcnt_t.
      Signed-off-by: default avatarTakashi Sato <sho@tnes.nec.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a0f62ac6
  32. 01 Feb, 2006 1 commit
  33. 28 Oct, 2005 1 commit
    • Al Viro's avatar
      [PATCH] gfp_t: infrastructure · af4ca457
      Al Viro authored
      
      
      Beginning of gfp_t annotations:
      
       - -Wbitwise added to CHECKFLAGS
       - old __bitwise renamed to __bitwise__
       - __bitwise defined to either __bitwise__ or nothing, depending on
         __CHECK_ENDIAN__ being defined
       - gfp_t switched from __nocast to __bitwise__
       - force cast to gfp_t added to __GFP_... constants
       - new helper - gfp_zone(); extracts zone bits out of gfp_t value and casts
         the result to int
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      af4ca457
  34. 08 Oct, 2005 1 commit
  35. 29 Aug, 2005 1 commit
  36. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4