Re: [PATCH 2.6.25-rc7 resubmit] Fix itimer/many thread hang.

Frank Mayhar
2008-04-01T21:47:46Z

On Tue, 2008-04-01 at 11:45 -0700, Andrew Morton wrote:
> On Fri, 28 Mar 2008 15:46:40 -0700
> Frank Mayhar <fmayhar@google.com> wrote:
>
> > asmlinkage long sys_times(struct tms __user * tbuf)
> > {
> > + struct thread_group_cputime thread_group_times;
> > +
> > /*
> > * In the SMP world we might just be unlucky and have one of
> > * the times increment as we use it. Since the value is an
> > @@ -873,19 +875,28 @@ asmlinkage long sys_times(struct tms __user * tbuf)
> > if (tbuf) {
> > struct tms tmp;
> > struct task_struct *tsk = current;
> > - struct task_struct *t;
> > cputime_t utime, stime, cutime, cstime;
> >
> > spin_lock_irq(&tsk->sighand->siglock);
> > - utime = tsk->signal->utime;
> > - stime = tsk->signal->stime;
> > - t = tsk;
> > - do {
> > - utime = cputime_add(utime, t->utime);
> > - stime = cputime_add(stime, t->stime);
> > - t = next_thread(t);
> > - } while (t != tsk);
> > -
> > + /*
> > + * If a POSIX interval timer is running use the process-wide
> > + * fields, else fall back to brute force.
> > + */
> > + if (sig->thread_group_times) {
>
> kernel/sys.c: In function 'sys_times':
> kernel/sys.c:885: error: 'sig' undeclared (first use in this function)

Thanks. As I said privately, I don't know how this snuck in but it's
certainly time to blow away my build tree and reapply the next patch
from scratch.

Speaking of which, expect that next patch in a day or two.