Messages in this thread | | | Date | Sat, 18 Dec 1999 03:07:24 +0100 (CET) | From | Andrea Arcangeli <> | Subject | for maintainers: all archs must be updated for 2.2.14 [Re: PPC SMP broken in 2.2.14pre14] |
| |
On Fri, 17 Dec 1999, Tom Sightler wrote:
>been broken somewhere in the 2.2.14pre series. I will attempt to determine
I had to break the handle_mm_fault API in 2.2.14pre2 to fix oom bugs. I updated myself only i386 and Alpha and then Dave fixed sparc and sparc64 in the middle of 2.2.14pre. Everything else is still broken in 2.2.14pre14 (s390 that seen the light in 2.2.14pre included).
Updating the other archs should be pretty easy by checking the changes in the other arch.
Basically now you have to check the retval of handle_mm_fault:
o if the retval is > 0 it means you can return from the exception and all gone right
o if the retval is == 0 you must send a sigbus to the process and return from the exception.
o if the retval is < 0 it means handle_mm_fault failed due oom. So if the fault happened in userspace you can do_exit(SIGKILL). If the fault happened in the kernel instead you should call the exception callback so the copy_user stuff will break and will return -EFAULT to the kernel. DETAIL: if the pid of the task is 1 you must instead sched-yield and try again later or init could be killed (init was used to die because the copy-user stuff was returning -EFAULT while receiving a signal and so init was getting a sigsegv by mistake).
ptrace must check the retval of handle_mm_fault as well (just copy the stuff in the just uptodate archs as it should be completly equivalent).
The arch/*/kernel/signal.c stuff was used to recall the copy-user stuff lots of times without checking the retval between each call. This mean that try_to_free_pages needed to fail _lots_ of times before the signal stuff had a chance to notice the oom/fault condition. That's why I added some more goto sigsegv in signal.c. It's not strictly necessary but without the additional checkes you risk to wait several seconds before the task will have a chance to be killed.
If you'll get in troubles don't esistate to ask.
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |