[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1287660312.3488.103.camel@twins>
Date: Thu, 21 Oct 2010 13:25:12 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: [RFC/RFT PATCH] sched: automated per tty task groups
On Thu, 2010-10-21 at 06:51 -0400, Mathieu Desnoyers wrote:
> * Mike Galbraith (efault@....de) wrote:
> [...]
> > +static void
> > +autogroup_attach_tty(struct task_struct *p, struct task_group **tg)
> > +{
> > + struct tty_struct *tty = p->signal->tty;
> > +
> > + if (!tty)
> > + return;
> > +
> > + *tg = p->signal->tty->tg;
> > +}
> > +
> > +static inline void
> > +autogroup_check_attach(struct task_struct *p, struct task_group **tg)
> > +{
> > + if (!sysctl_sched_autogroup_enabled || *tg != &root_task_group ||
> > + p->sched_class != &fair_sched_class)
> > + return;
> > +
> > + rcu_read_lock();
> > +
> > + autogroup_attach_tty(p, tg);
> > +
> > + rcu_read_unlock();
> > +}
> > +
> Meanwhile, a little question about locking here: how is
> the read lock supposed to protect from p->signal (and p->signal->tty)
> modifications ? What's the locking scheme here ? So maybe just simple
> rcu_dereference are missing, or maybe the tsk->sighand->siglock might be
> required. In all cases, I feel something is missing there.
Oleg, could you comment?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists