Commit graph

6 commits

Author SHA1 Message Date
David S. Miller
a3f9985843 [SPARC64]: Move kernel unaligned trap handlers into assembler file.
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-08-19 15:55:33 -07:00
David S. Miller
db7d9a4eb7 [SPARC64]: Move syscall success and newchild state out of thread flags.
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-24 19:36:26 -07:00
David S. Miller
f7ceba360c [SPARC64]: Add syscall auditing support.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-10 19:29:45 -07:00
David S. Miller
bb49bcda15 [SPARC64]: Add SECCOMP support.
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-10 16:49:28 -07:00
Jesper Juhl
dcd497f99a [PATCH] streamline preempt_count type across archs
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-06-23 09:45:19 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00