From: Martin J. B. <mb...@ar...> - 2003-05-11 05:59:07
|
The patchset contains mainly scalability and NUMA stuff, and anything else that stops things from irritating me. It's meant to be pretty stable, not so much a testing ground for new stuff. I'd be very interested in feedback from anyone willing to test on any platform, however large or small. ftp://ftp.kernel.org/pub/linux/kernel/people/mbligh/2.5.69/patch-2.5.69-mjb1.bz2 additional patches that can be applied if desired: (these two form the qlogic feral driver) ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.67/2.5.67-mm1/broken-out/linux-isp.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.67/2.5.67-mm1/broken-out/isp-update-1.patch Since 2.5.68-mjb3 (~ = changed, + = added, - = dropped) Notes: Now in Linus' tree: - node_balance Martin J. Bligh Turn on node balance - it's not overagressive anymore - sisfix (equivalent fix) Martin J. Bligh Fix warning & bug in sis900 driver - diskstats Rick Lindsley Make disk stats available in /proc so they scale to lotsa disks. - lost_tick_fix John Stultz Lost tick stuff - dentry_stat_fix Maneesh corrects the dentry_stat.nr_unused calculation - follow_hugetlb_page Bill Irwin Fix follow_hugetlb_page() - hugetlb_mem_enough Bill Irwin fixes an overflow when there is more than 4GB of hugetlb - aio_fix Badari Pulavarty Fix something in AIO - oom_locking Bill Irwin / Robert Love Fix OOM locking Dropped until I get an updated version because I'm too idle to merge them ;-) - separate_pmd Dave Hansen Separate kernel pmd per process - banana_split Dave Hansen Provide non PMD aligned splits with PAE mode (eg 3.5:0.5) New: + fsaio_vs_aio_fix Janet Morgan (?) Fix up a fistfight between AIO and fsAIO. Pending: Hyperthreaded scheduler (Ingo Molnar) scheduler callers profiling (Anton or Bill Hartner) Child runs first (akpm) Kexec e1000 fixes Update the lost timer ticks code Present in this patch: early_printk Dave Hansen et al. Allow printk before console_init confighz Andrew Morton / Dave Hansen Make HZ a config option of 100 Hz or 1000 Hz config_page_offset Dave Hansen / Andrea Make PAGE_OFFSET a config option numameminfo Martin Bligh / Keith Mannthey Expose NUMA meminfo information under /proc/meminfo.numa schedstat Rick Lindsley Provide stats about the scheduler under /proc/schedstat schedstat2 Rick Lindsley Provide more stats about the scheduler under /proc/schedstat schedstat-scripts Rick Lindsley Provide some scripts for schedstat analysis under scripts/ sched_tunables Robert Love Provide tunable parameters for the scheduler (+ NUMA scheduler) irq_affinity Martin J. Bligh Workaround for irq_affinity on clustered apic mode systems (eg x440) partial_objrmap Dave McCracken Object based rmap for filebacked pages. objrmap_fix Dave McCracken Fix detection of anon pages objrmap_fixes Dave McCracken / Hugh Dickins Fix up some mapped sizing bugs in objrmap objrmap_mapcount Dave McCracken Fix up some mapped sizing bugs in objrmap kgdb Andrew Morton The older version of kgdb, synched with 2.5.54-mm1 kprobes Vamsi Krishna S Add kernel probes hooks to the kernel thread_info_cleanup (4K stacks pt 1) Dave Hansen / Ben LaHaise Prep work to reduce kernel stacks to 4K interrupt_stacks (4K stacks pt 2) Dave Hansen / Ben LaHaise Create a per-cpu interrupt stack. stack_usage_check (4K stacks pt 3) Dave Hansen / Ben LaHaise Check for kernel stack overflows. 4k_stack (4K stacks pt 4) Dave Hansen Config option to reduce kernel stacks to 4K fix_kgdb Dave Hansen Fix interaction between kgdb and 4K stacks stacks_from_slab William Lee Irwin Take kernel stacks from the slab cache, not page allocation. thread_under_page William Lee Irwin Fix THREAD_SIZE < PAGE_SIZE case lkcd LKCD team Linux kernel crash dump support percpu_loadavg Martin J. Bligh Provide per-cpu loadaverages, and real load averages spinlock_inlining Andrew Morton Inline spinlocks for profiling. Made into a ugly config option by me. summit_pcimap Matt Dobson Provide pci bus -> node mapping for x440 reiserfs_dio Mingming Cao DIO for Reiserfs sched_interactive Ingo Molnar Bugfix for interactive scheduler kgdb_cleanup Martin J. Bligh Stop kgdb renaming schedule to do_schedule when it's not even enabled acenic_fix Martin J. Bligh Fix warning in acenic driver local_balance_exec Martin J. Bligh Modify balance_exec to use node-local queues when idle membind Matt Dobson NUMA memory binding API tcp_speedup Martin J. Bligh Speedup TCP (avoid double copy) as suggested by Linus early_printk_fix Keith Mannthey Fix commandline parsing in early printk (yay!) disable preempt Martin J. Bligh I broke preempt somehow, temporarily disable it to stop accidents sched_idle Martin J. Bligh Call load_balance with proper idle flag (pointed out by John Hawkes) ppc64 fixes Anton Blanchard Various PPC64 fixes / updates numameminfo fix Martin J. Bligh Correct /proc/meminfo.numa for zholes_size. more_async Andrew Morton Make MS_ASYNC more async config_debug Martin J. Bligh Make '-g' for the kernel a config option akpm_bear_pit Andrew Morton Add a printk for some buffer error I was hitting 32bit_dev_t Andries Brouwer Make dev_t 32 bit dynamic_hd_struct Badari Pulavarty Allocate hd_structs dynamically devfs_fixup Badari Pulavarty ? Fix some random thing in devfs iosched_hashes Badari Pulavarty Twiddle with the iosched hash tables for fun & profit lotsa_sds Badari Pulavarty Create some insane number of sds per_node_idt Zwane Mwaikambo Per node IDT so we can do silly numbers of IO-APICs on NUMA-Q tulip_warning Dave Hansen Fix silly warning in tulip driver for PAE mode warn_e1000 Dave Hansen Kill e1000 warning pidmaps_nodepages Dave Hansen Provide per-pid node mem usage info config_numasched Dave Hansen Turn NUMA scheduler into a config option lockmeter_tytso Ted Tso Fix lockmeter aiofix2 Mingming Cao fixed a bug in ioctx_alloc() config_irqbal Keith Mannthey Make irqbalance a config option fs_aio_1_retry Suparna Bhattacharya Filesystem aio. Chapter 1 fs_aio_2_read Suparna Bhattacharya Filesystem aio. Chapter 2 fs_aio_3_write Suparna Bhattacharya Filesystem aio. Chapter 3 fs_aio_4_down_wq Suparna Bhattacharya Filesystem aio. Chapter 4 fs_aio_5_wrdown_wq Suparna Bhattacharya Filesystem aio. Chapter 5 fs_aio_6_bread_wq Suparna Bhattacharya Filesystem aio. Chapter 6 fs_aio_7_ext2getblk_wq Suparna Bhattacharya Filesystem aio. Chapter 7 fs_aio_8_down_wq-ppc64 Suparna Bhattacharya Filesystem aio. Chapter 8 fs_aio_9_down_wq-x86_64 Suparna Bhattacharya Filesystem aio. Chapter 9 pae_vmalloc Dave Hansen Stop PAE mode from piddling with PGD entries from vmalloc. -mjb Martin J. Bligh Add a tag to the makefile |
From: Zwane M. <zw...@li...> - 2003-05-11 13:42:12
|
Any particular reason why CONFIG_PREEMPT is commented out? Zwane -- function.linuxpower.ca |
From: Martin J. B. <mb...@ar...> - 2003-05-11 15:27:21
|
> Any particular reason why CONFIG_PREEMPT is commented out? Yeah, 'cause it's broken ;-) If someone can figure out what broke it, (something in my tree) I'll turn it back on. Else it stays disabled as a footguard for poor innocents ;-) M. |
From: William L. I. I. <wl...@ho...> - 2003-05-12 13:31:05
|
On Sat, May 10, 2003 at 08:44:09PM -0700, Martin J. Bligh wrote: > thread_info_cleanup (4K stacks pt 1) Dave Hansen / Ben LaHaise > Prep work to reduce kernel stacks to 4K > interrupt_stacks (4K stacks pt 2) Dave Hansen / Ben LaHaise > Create a per-cpu interrupt stack. > stack_usage_check (4K stacks pt 3) Dave Hansen / Ben LaHaise > Check for kernel stack overflows. > 4k_stack (4K stacks pt 4) Dave Hansen > Config option to reduce kernel stacks to 4K diff -urpN linux-2.5.69/include/asm-i386/processor.h kstk-2.5.69-1/include/asm-i386/processor.h --- linux-2.5.69/include/asm-i386/processor.h 2003-05-04 16:53:00.000000000 -0700 +++ kstk-2.5.69-1/include/asm-i386/processor.h 2003-05-12 06:05:39.000000000 -0700 @@ -470,8 +470,8 @@ extern int kernel_thread(int (*fn)(void extern unsigned long thread_saved_pc(struct task_struct *tsk); unsigned long get_wchan(struct task_struct *p); -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) +#define KSTK_EIP(task) (((unsigned long *)(task)->thread_info)[THREAD_SIZE/sizeof(unsigned long) - 5]) +#define KSTK_ESP(task) (((unsigned long *)(task)->thread_info)[THREAD_SIZE/sizeof(unsigned long) - 2]) struct microcode { unsigned int hdrver; |
From: Martin J. B. <mb...@ar...> - 2003-05-12 14:55:18
|
--On Monday, May 12, 2003 06:29:39 -0700 William Lee Irwin III <wl...@ho...> wrote: > On Sat, May 10, 2003 at 08:44:09PM -0700, Martin J. Bligh wrote: >> thread_info_cleanup (4K stacks pt 1) Dave Hansen / Ben LaHaise >> Prep work to reduce kernel stacks to 4K >> interrupt_stacks (4K stacks pt 2) Dave Hansen / Ben LaHaise >> Create a per-cpu interrupt stack. >> stack_usage_check (4K stacks pt 3) Dave Hansen / Ben LaHaise >> Check for kernel stack overflows. >> 4k_stack (4K stacks pt 4) Dave Hansen >> Config option to reduce kernel stacks to 4K > > > diff -urpN linux-2.5.69/include/asm-i386/processor.h kstk-2.5.69-1/include/asm-i386/processor.h > --- linux-2.5.69/include/asm-i386/processor.h 2003-05-04 16:53:00.000000000 -0700 > +++ kstk-2.5.69-1/include/asm-i386/processor.h 2003-05-12 06:05:39.000000000 -0700 > @@ -470,8 +470,8 @@ extern int kernel_thread(int (*fn)(void > extern unsigned long thread_saved_pc(struct task_struct *tsk); > > unsigned long get_wchan(struct task_struct *p); > -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) > -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) > +#define KSTK_EIP(task) (((unsigned long *)(task)->thread_info)[THREAD_SIZE/sizeof(unsigned long) - 5]) > +#define KSTK_ESP(task) (((unsigned long *)(task)->thread_info)[THREAD_SIZE/sizeof(unsigned long) - 2]) > > struct microcode { > unsigned int hdrver; Can I get some sort of vague explanation please? ;-) M. |
From: Dave H. <hav...@us...> - 2003-05-12 15:07:05
|
Martin J. Bligh wrote: > --On Monday, May 12, 2003 06:29:39 -0700 William Lee Irwin III <wl...@ho...> wrote: > > >>On Sat, May 10, 2003 at 08:44:09PM -0700, Martin J. Bligh wrote: >> >>>thread_info_cleanup (4K stacks pt 1) Dave Hansen / Ben LaHaise >>> Prep work to reduce kernel stacks to 4K >>>interrupt_stacks (4K stacks pt 2) Dave Hansen / Ben LaHaise >>> Create a per-cpu interrupt stack. >>>stack_usage_check (4K stacks pt 3) Dave Hansen / Ben LaHaise >>> Check for kernel stack overflows. >>>4k_stack (4K stacks pt 4) Dave Hansen >>> Config option to reduce kernel stacks to 4K >> >> >>diff -urpN linux-2.5.69/include/asm-i386/processor.h kstk-2.5.69-1/include/asm-i386/processor.h >>--- linux-2.5.69/include/asm-i386/processor.h 2003-05-04 16:53:00.000000000 -0700 >>+++ kstk-2.5.69-1/include/asm-i386/processor.h 2003-05-12 06:05:39.000000000 -0700 >>@@ -470,8 +470,8 @@ extern int kernel_thread(int (*fn)(void >> extern unsigned long thread_saved_pc(struct task_struct *tsk); >> >> unsigned long get_wchan(struct task_struct *p); >>-#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) >>-#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) >>+#define KSTK_EIP(task) (((unsigned long *)(task)->thread_info)[THREAD_SIZE/sizeof(unsigned long) - 5]) >>+#define KSTK_ESP(task) (((unsigned long *)(task)->thread_info)[THREAD_SIZE/sizeof(unsigned long) - 2]) >> >> struct microcode { >> unsigned int hdrver; > > Can I get some sort of vague explanation please? ;-) Wow, that's intuitive :) They're trying to access the variables that have been pushed onto the top of the stack. The thread_info field points to the bottom of the kernel's stack (no matter how big it is). I don't know where the -5 and -2 come from. It needs a big, fat stinking comment. -- Dave Hansen hav...@us... |
From: William L. I. I. <wl...@ho...> - 2003-05-13 01:24:55
|
On Mon, May 12, 2003 at 08:05:15AM -0700, Dave Hansen wrote: > Wow, that's intuitive :) > They're trying to access the variables that have been pushed onto the > top of the stack. The thread_info field points to the bottom of the > kernel's stack (no matter how big it is). I don't know where the -5 and > -2 come from. It needs a big, fat stinking comment. I'm not 100% convinced it DTRT on modern kernels. I vaguely wonder if the following would be more appropriate. Shame the typedef isn't there yet; the _struct suffix is an eyesore. -- wli diff -prauN linux-2.5.69/include/asm-i386/processor.h kstk-2.5.69-1/include/asm-i386/processor.h --- linux-2.5.69/include/asm-i386/processor.h 2003-05-04 16:53:00.000000000 -0700 +++ kstk-2.5.69-1/include/asm-i386/processor.h 2003-05-12 14:02:13.000000000 -0700 @@ -96,9 +96,9 @@ extern struct cpuinfo_x86 cpu_data[]; extern char ignore_fpu_irq; -extern void identify_cpu(struct cpuinfo_x86 *); -extern void print_cpu_info(struct cpuinfo_x86 *); -extern void dodgy_tsc(void); +void identify_cpu(struct cpuinfo_x86 *); +void print_cpu_info(struct cpuinfo_x86 *); +void dodgy_tsc(void); /* * EFLAGS bits @@ -457,21 +457,21 @@ struct task_struct; struct mm_struct; /* Free all resources held by a thread. */ -extern void release_thread(struct task_struct *); +void release_thread(struct task_struct *); /* Prepare to copy thread state - unlazy all lazy status */ -extern void prepare_to_copy(struct task_struct *tsk); +void prepare_to_copy(struct task_struct *); /* * create a kernel thread without removing it from tasklists */ -extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags); +int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags); -extern unsigned long thread_saved_pc(struct task_struct *tsk); +unsigned long thread_saved_pc(struct task_struct *); -unsigned long get_wchan(struct task_struct *p); -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) +unsigned long get_wchan(struct task_struct *); +#define KSTK_EIP(task) ((task)->thread.eip) +#define KSTK_ESP(task) ((task)->thread.esp) struct microcode { unsigned int hdrver; |
From: Martin J. B. <mb...@ar...> - 2003-05-13 05:55:45
|
>> Wow, that's intuitive :) >> They're trying to access the variables that have been pushed onto the >> top of the stack. The thread_info field points to the bottom of the >> kernel's stack (no matter how big it is). I don't know where the -5 and >> -2 come from. It needs a big, fat stinking comment. > > I'm not 100% convinced it DTRT on modern kernels. I vaguely wonder if > the following would be more appropriate. Shame the typedef isn't there > yet; the _struct suffix is an eyesore. So are the new bits of the patch related to the KSTK_E* bit? They don't seem to be ... however, this bit looks really good: > -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) > -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) > +#define KSTK_EIP(task) ((task)->thread.eip) > +#define KSTK_ESP(task) ((task)->thread.esp) Can I assume it's tested, or does it need someone to do that? Thanks, M. |
From: William L. I. I. <wl...@ho...> - 2003-05-13 06:28:50
|
At some point in the past, someone wrote: >> I'm not 100% convinced it DTRT on modern kernels. I vaguely wonder if >> the following would be more appropriate. Shame the typedef isn't there >> yet; the _struct suffix is an eyesore. On Mon, May 12, 2003 at 08:41:22PM -0700, Martin J. Bligh wrote: > So are the new bits of the patch related to the KSTK_E* bit? > They don't seem to be ... however, this bit looks really good: Random incidental cleanups. At some point in the past, someone wrote: >> -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) >> -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) >> +#define KSTK_EIP(task) ((task)->thread.eip) >> +#define KSTK_ESP(task) ((task)->thread.esp) On Mon, May 12, 2003 at 08:41:22PM -0700, Martin J. Bligh wrote: > Can I assume it's tested, or does it need someone to do that? Not tested. AFAICT it's returning random garbage somewhere near the beginning of the kernel stack now but haven't checked the answers generated at runtime to see if they look valid. This at least vaguely resembles the intent of the code, but it might actually want (task)->thread.esp0 or other such nonsense and so on now that I think about it some more. At the very least it looks plausible and doesn't perform accesses that aren't actually on the stack as they're supposed to be when you shrink the stack to 4KB. AIUI those kinds of out-of-bounds accesses to potentially freed memory are oopsable with some debugging patches like manfred's that unmaps freed pages. -- wli |
From: Andi K. <ak...@su...> - 2003-05-13 06:42:28
|
> > -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) > > -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) > > +#define KSTK_EIP(task) ((task)->thread.eip) > > +#define KSTK_ESP(task) ((task)->thread.esp) > > Can I assume it's tested, or does it need someone to do that? It's broken. It will report the kernel values, not the user values like the previous version and also get it wrong for the current task (KSTK_* is really a misnomer, it should be USTK_*. WCHAN is handled by a different mechanism) Something like this should work (untested) #define KSTK_PTREGS(tsk) \ ((struct pt_regs *)((unsigned long)((tsk)->thread_info) + THREAD_SIZE) - 1) #define KSTK_EIP(tsk) (KSTK_PTREGS(tsk)->eip) #define KSTK_ESP(tsk) (KSTK_PTREGS(tsk)->esp) -Andi |
From: William L. I. I. <wl...@ho...> - 2003-05-12 15:29:20
|
On Mon, May 12, 2003 at 05:40:55AM -0700, Martin J. Bligh wrote: > Can I get some sort of vague explanation please? ;-) How obvious does it have to be? Those are trying to fish out the 2nd and 5th words from the top of the stack. Magic numbers stopped working; symbolic constants save the day. -- wli |
From: Dave H. <hav...@us...> - 2003-05-12 15:13:04
|
William Lee Irwin III wrote: > On Mon, May 12, 2003 at 05:40:55AM -0700, Martin J. Bligh wrote: > >>Can I get some sort of vague explanation please? ;-) > > How obvious does it have to be? More obvious than that :) > Those are trying to fish out the 2nd and 5th words from the top of the > stack. Magic numbers stopped working; symbolic constants save the day. I guess I'm not understanding _why_ they're guaranteed to be there. -- Dave Hansen hav...@us... |
From: Martin J. B. <mb...@ar...> - 2003-05-12 16:51:38
|
> Me >>> Can I get some sort of vague explanation please? ;-) > > Bill > How obvious does it have to be? More obvious than that, if I've never looked at it before ;-) > Dave > They're trying to access the variables that have been pushed onto the > top of the stack. The thread_info field points to the bottom of the > kernel's stack (no matter how big it is). I don't know where the -5 and > -2 come from. It needs a big, fat stinking comment. OK, so maybe I'm still asleep, but I don't see why the hardcoded magic constant (grrr) is 4096 in mainline, when the stacksize is 8K. Presumably the 1019*4 makes up the rest of it? Maybe the real question is what the hell was whoever wrote that in the first place smoking ? ;-) Why on earth would you skip halfway through the stack with one stupid magic constant, and then the rest of the way with another? Perhaps I'm just making the mistake of assuming the existing code was sane ... I was just uncomfortable because I didn't understand why it was like that before, I guess. > Dave > I don't know where the -5 and > -2 come from. It needs a big, fat stinking comment. > > Bill > Those are trying to fish out the 2nd and 5th words from the top of the > stack. Magic numbers stopped working; symbolic constants save the day. Right, I see what you're doing now. But would be nice (as Dave said) if those magic numbers were no longer magic numbers (as you did for the other part of it), if that's possible, or commented. Not that you haven't vastly improved it already ;-) Thanks, M. |
From: Dave H. <hav...@us...> - 2003-05-12 15:36:05
|
Martin J. Bligh wrote: > OK, so maybe I'm still asleep, but I don't see why the hardcoded > magic constant (grrr) is 4096 in mainline, when the stacksize is 8K. > Presumably the 1019*4 makes up the rest of it? Maybe the real question > is what the hell was whoever wrote that in the first place smoking ? ;-) > Why on earth would you skip halfway through the stack with one stupid > magic constant, and then the rest of the way with another? You can go ask the author: http://linus.bkbits.net:8080/linux-2.5/diffs/include/asm-i386/processor.h@1.12?nav=index.html|src/|src/include|src/include/asm-i386|hist/include/asm-i386/processor.h -- Dave Hansen hav...@us... |
From: Martin J. B. <mb...@ar...> - 2003-05-12 16:06:37
|
--On Monday, May 12, 2003 08:34:13 -0700 Dave Hansen <hav...@us...> wrote: > Martin J. Bligh wrote: >> OK, so maybe I'm still asleep, but I don't see why the hardcoded >> magic constant (grrr) is 4096 in mainline, when the stacksize is 8K. >> Presumably the 1019*4 makes up the rest of it? Maybe the real question >> is what the hell was whoever wrote that in the first place smoking ? ;-) >> Why on earth would you skip halfway through the stack with one stupid >> magic constant, and then the rest of the way with another? > > You can go ask the author: > > http://linus.bkbits.net:8080/linux-2.5/diffs/include/asm-i386/processor.h@1.12?nav=index.html|src/|src/include|src/include/asm-i386|hist/include/asm-i386/processor.h -#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)))[1019]) -#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)))[1022]) ... +#define KSTK_EIP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1019]) +#define KSTK_ESP(tsk) (((unsigned long *)(4096+(unsigned long)(tsk)->thread_info))[1022]) Nope, not his fault, really. M. |