[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150214205745.GA15695@redhat.com>
Date: Sat, 14 Feb 2015 21:57:45 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Davidlohr Bueso <dave@...olabs.net>
Cc: Darren Hart <darren@...art.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jerome Marchand <jmarchan@...hat.com>,
Larry Woodman <lwoodman@...hat.com>,
Mateusz Guzik <mguzik@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] futex: check PF_KTHREAD rather than !p->mm to
filter out kthreads
On 02/14, Davidlohr Bueso wrote:
>
> On Mon, 2015-02-02 at 15:05 +0100, Oleg Nesterov wrote:
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -900,7 +900,7 @@ static int attach_to_pi_owner(u32 uval, union futex_key *key,
> > if (!p)
> > return -ESRCH;
> >
> > - if (!p->mm) {
> > + if (unlikely(p->flags & PF_KTHREAD)) {
> > put_task_struct(p);
> > return -EPERM;
> > }
>
> Futexes aren't the only naughty checkers,
Yes, this is the common mistake,
> a quick search shows that, at
> least, the oom killer and proc have this same problem.
oom looks fine, note the PF_KTHREAD check in oom_unkillable(). It check ->mm
for another reason, to figure out if this task has passed exit_mm() or not.
proc looks fine too at first glance... we do not care if this mm was adopted
via use_mm() or not.
> Should we make
> this generic and update accordingly? ie:
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8db31ef..b0d37d6 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1991,6 +1991,11 @@ extern void thread_group_cputime_adjusted(struct task_struct *p, cputime_t *ut,
> #define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
> #define used_math() tsk_used_math(current)
>
> +static inline bool task_is_kthread(struct task_struct *task)
> +{
> + return task->flags & PF_KTHREAD;
> +}
Perhaps... but PF_KTHREAD looks self-documented too ;)
Oleg.
--
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