aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-sparc64/thread_info.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2005-08-19[SPARC64]: Move kernel unaligned trap handlers into assembler file.David S. Miller1-0/+5
GCC 4.x really dislikes the games we are playing in unaligned.c, and the cleanest way to fix this is to move things into assembler. Noted by Al Viro. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-24[SPARC64]: Move syscall success and newchild state out of thread flags.David S. Miller1-5/+7
These two bits were accesses non-atomically from assembler code. So, in order to eliminate any potential races resulting from that, move these pieces of state into two bytes elsewhere in struct thread_info. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-10[SPARC64]: Add syscall auditing support.David S. Miller1-3/+5
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-10[SPARC64]: Add SECCOMP support.David S. Miller1-1/+2
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-23[PATCH] streamline preempt_count type across archsJesper Juhl1-1/+1
The preempt_count member of struct thread_info is currently either defined as int, unsigned int or __s32 depending on arch. This patch makes the type of preempt_count an int on all archs. Having preempt_count be an unsigned type prevents the catching of preempt_count < 0 bugs, and using int on some archs and __s32 on others is not exactely "neat" - much nicer when it's just int all over. A previous version of this patch was already ACK'ed by Robert Love, and the only change in this version of the patch compared to the one he ACK'ed is that this one also makes sure the preempt_count member is consistently commented. Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+252
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!