From: Gerd K. <kr...@by...> - 2004-02-23 17:28:27
|
Hi, You might have noticed already that in latest linus tree um doesn't build any more. The reason is that sys_sched_setscheduler() is declared now in linux/sched.h, which conflicts with the declaration in arch/um/kernel/sys_call_table.c. As quick+dirty fix I've just commented the declaration. It builds now, but gives a warning (which is harmless I think as the exact type of the function shouldn't matter for the syscall table). Anyone has a better/cleaner fix for that? Gerd --- linux-2004-02-22/arch/um/kernel/sys_call_table.c~ 2004-02-23 15:39:51.000000000 +0100 +++ linux-2004-02-22/arch/um/kernel/sys_call_table.c 2004-02-23 17:30:16.995802718 +0100 @@ -151,7 +151,7 @@ extern syscall_handler_t sys_munlockall; extern syscall_handler_t sys_sched_setparam; extern syscall_handler_t sys_sched_getparam; -extern syscall_handler_t sys_sched_setscheduler; +//extern syscall_handler_t sys_sched_setscheduler; extern syscall_handler_t sys_sched_getscheduler; extern syscall_handler_t sys_sched_get_priority_max; extern syscall_handler_t sys_sched_get_priority_min; |
From: BlaisorBlade <bla...@ya...> - 2004-02-25 19:53:39
|
Alle 18:20, luned=EC 23 febbraio 2004, Gerd Knorr ha scritto: > Hi, > > You might have noticed already that in latest linus tree um doesn't > build any more. The reason is that sys_sched_setscheduler() is declared > now in linux/sched.h, which conflicts with the declaration in > arch/um/kernel/sys_call_table.c. As quick+dirty fix I've just commented > the declaration. It builds now, but gives a warning (which is harmless I > think as the exact type of the function shouldn't matter for the syscall > table). Anyone has a better/cleaner fix for that? I agree that it's harmless (you can add a typecast as it is done for other= =20 functions there). By the way (unrelated) you could maybe remove include=20 "linux/sys.h" since it claims to be unused. Nothing cleaner since avoiding the inclusion of sched.h is impossible. And= =20 this is the fix used for similar cases in that file. Also, please fix this line: __NR_sched_yield ] =3D (syscall_handler_t *) yield It should refer to sys_sched_yield. yield() is not even asmlinkage, so this= =20 could case serious problems, and it is commented as "for kernel usage". Als= o=20 I checked i386 syscall table, and it uses sys_sched_yield. Bye =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Gerd K. <kr...@by...> - 2004-02-25 21:49:24
|
BlaisorBlade <bla...@ya...> writes: > __NR_sched_yield ] = (syscall_handler_t *) yield > > It should refer to sys_sched_yield. yield() is not even asmlinkage, so this > could case serious problems, and it is commented as "for kernel usage". Also > I checked i386 syscall table, and it uses sys_sched_yield. There is another related one (asmlinkage where it shouldn't be) in mprotect.c. With the new CONFIG_REGPARM config option it becomes really important to get that right ... Gerd Index: linux-2.6.3/mm/mprotect.c =================================================================== --- linux-2.6.3.orig/mm/mprotect.c +++ linux-2.6.3/mm/mprotect.c @@ -221,7 +221,7 @@ fail: return error; } -asmlinkage long +long do_mprotect(struct mm_struct *mm, unsigned long start, size_t len, unsigned long prot) { |
From: BlaisorBlade <bla...@ya...> - 2004-02-26 19:36:57
|
Alle 22:12, mercoled=EC 25 febbraio 2004, Gerd Knorr ha scritto: > BlaisorBlade <bla...@ya...> writes: > > __NR_sched_yield ] =3D (syscall_handler_t *) yield > > > > It should refer to sys_sched_yield. yield() is not even asmlinkage, so > > this could case serious problems, and it is commented as "for kernel > > usage". Also I checked i386 syscall table, and it uses sys_sched_yield. > > There is another related one (asmlinkage where it shouldn't be) in > mprotect.c. Good catch. > With the new CONFIG_REGPARM config option it becomes > really important to get that right ... Yes, however I think that one asmlinkage more is not very bad (old conventi= on=20 used where the call can be optimized), but that a missing asmlinkage could = be=20 crashy. At least until the prototype is correct; I just noticed that=20 do_mprotect is protoized without asmlinkage - and this can be actually=20 crashy. Luckily CONFIG_REGPARM is not in the stock kernel. If it were, that could have explained some Skas-2.6 crashes which can be se= en=20 here (there is already one BUG hit which explains it in part, see here: "Ho= st=20 2.6.2/3 + CFQ + BlaisorBlade patches"... but on one kernel it Oopsed and on= =20 another it crashed, so there could be something else). =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Gerd K. <kr...@by...> - 2004-02-26 21:30:01
|
BlaisorBlade <bla...@ya...> writes: > crashy. Luckily CONFIG_REGPARM is not in the stock kernel. It is in Linus' bk tree, so 2.6.4 will have that ... Gerd |