summaryrefslogtreecommitdiffstats
path: root/include/asm-sparc64/thread_info.h
Commit message (Collapse)AuthorAgeFilesLines
* sparc64: Use a TS_RESTORE_SIGMASKDavid S. Miller2008-05-121-4/+24
| | | | | | | This mirrors x86 changeset 5a8da0ea82db6fa9737041381079fd16f25dcce2 ("signals: x86 TS_RESTORE_SIGMASK") on sparc64. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc: Remove old style signal frame support.David S. Miller2008-04-271-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Back around the same time we were bootstrapping the first 32-bit sparc Linux kernel with a SunOS userland, we made the signal frame match that of SunOS. By the time we even started putting together a native Linux userland for 32-bit Sparc we realized this layout wasn't sufficient for Linux's needs. Therefore we changed the layout, yet kept support for the old style signal frame layout in there. The detection mechanism is that we had sys_sigaction() start passing in a negative signal number to indicate "new style signal frames please". Anyways, no binaries exist in the world that use the old stuff. In fact, I bet Jakub Jelinek and myself are the only two people who ever had such binaries to be honest. So let's get rid of this stuff. I added an assertion using WARN_ON_ONCE() that makes sure 32-bit applications are passing in that negative signal number still. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Eliminate NR_CPUS limitations.David S. Miller2007-05-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Cheetah systems can have cpuids as large as 1023, although physical systems don't have that many cpus. Only three limitations existed in the kernel preventing arbitrary NR_CPUS values: 1) dcache dirty cpu state stored in page->flags on D-cache aliasing platforms. With some build time calculations and some build-time BUG checks on page->flags layout, this one was easily solved. 2) The cheetah XCALL delivery code could only handle a cpumask with up to 32 cpus set. Some simple looping logic clears that up too. 3) thread_info->cpu was a u8, easily changed to a u16. There are a few spots in the kernel that still put NR_CPUS sized arrays on the kernel stack, but that's not a sparc64 specific problem. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Correctable ECC errors cannot occur at trap level > 0.David S. Miller2006-03-201-6/+3
| | | | | | | | | | | | | The are distrupting, which by the sparc v9 definition means they can only occur when interrupts are enabled in the %pstate register. This never occurs in any of the trap handling code running at trap levels > 0. So just mark it as an unexpected trap. This allows us to kill off the cee_stuff member of struct thread_info. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC]: Add support for *at(), ppoll, and pselect syscalls.David S. Miller2006-01-191-3/+3
| | | | | | | | | | This also includes by necessity _TIF_RESTORE_SIGMASK support, which actually resulted in a lot of cleanups. The sparc signal handling code is quite a mess and I should clean it up some day. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Move kernel unaligned trap handlers into assembler file.David S. Miller2005-08-191-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>
* [SPARC64]: Move syscall success and newchild state out of thread flags.David S. Miller2005-07-241-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>
* [SPARC64]: Add syscall auditing support.David S. Miller2005-07-101-3/+5
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Add SECCOMP support.David S. Miller2005-07-101-1/+2
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] streamline preempt_count type across archsJesper Juhl2005-06-231-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>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-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!
OpenPOWER on IntegriCloud