Messages in this thread Patch in this message | | | Date | Mon, 15 Nov 2004 15:43:46 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] -mm check_rlimit oops on p->signal |
| |
Hugh Dickins <hugh@veritas.com> wrote: > > + if (likely(p->signal && p->exit_state < EXIT_ZOMBIE)) {
Worried. This places an ordering interpretation on TASK_* and EXIT_* which AFAIK hadn't been there beforehand. If someone later comes along and adds
#define TASK_DOODLING 64
then we lose.
I wonder if for clarity and future-safety we should do something like:
--- 25/include/linux/sched.h~task-exit_state-clarity Mon Nov 15 15:40:24 2004 +++ 25-akpm/include/linux/sched.h Mon Nov 15 15:42:40 2004 @@ -105,13 +105,20 @@ extern unsigned long nr_iowait(void); #include <asm/processor.h> +/* + * Tasks whose exit_state is less that TASK_EXIT_MARKER are considered to + * be still running. Tasks whose exit_state is greater than TASK_EXIT_MARKER + * are in the process of exitting. TASK_EXIT_MARKER is never actually set in + * task_struct.exit_state. + */ #define TASK_RUNNING 0 #define TASK_INTERRUPTIBLE 1 #define TASK_UNINTERRUPTIBLE 2 #define TASK_STOPPED 4 #define TASK_TRACED 8 -#define EXIT_ZOMBIE 16 -#define EXIT_DEAD 32 +#define TASK_EXIT_MARKER 16 +#define EXIT_ZOMBIE 32 +#define EXIT_DEAD 64 #define __set_task_state(tsk, state_value) \ do { (tsk)->state = (state_value); } while (0) _ It seems a bit dorky for some reason... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |