linux-kernel - Re: [kernel.org users] [KORG] Panics on master backend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Aug 2011 12:24:32 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Frank Rowand <frank.rowand@...sony.com>,
	linux-kernel <linux-kernel@...r.kernel.org>, users@...nel.org,
	hch <hch@...radead.org>, "yong.zhang0" <yong.zhang0@...il.com>,
	scameron@...rdog.cce.hp.com,
	"James E.J. Bottomley" <jejb@...isc-linux.org>,
	Jens Axboe <jaxboe@...ionio.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [kernel.org users] [KORG] Panics on master backend

On Wed, 2011-08-24 at 18:08 +0200, Oleg Nesterov wrote:
> Looking at the next emails, I guess this is already off-topic, but still...
> 
> On 08/23, Peter Zijlstra wrote:
> >
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -2630,7 +2630,6 @@ static void ttwu_queue_remote(struct task_struct *p, int cpu)
> >  		smp_send_reschedule(cpu);
> >  }
> >
> > -#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
> >  static int ttwu_activate_remote(struct task_struct *p, int wake_flags)
> >  {
> >  	struct rq *rq;
> > @@ -2647,7 +2646,6 @@ static int ttwu_activate_remote(struct task_struct *p, int wake_flags)
> >  	return ret;
> >
> >  }
> > -#endif /* __ARCH_WANT_INTERRUPTS_ON_CTXSW */
> >  #endif /* CONFIG_SMP */
> >
> >  static void ttwu_queue(struct task_struct *p, int cpu)
> > @@ -2705,7 +2703,6 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> >  	 * this task as prev, wait until its done referencing the task.
> >  	 */
> >  	while (p->on_cpu) {
> > -#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
> >  		/*
> >  		 * In case the architecture enables interrupts in
> >  		 * context_switch(), we cannot busy wait, since that
> > @@ -2713,11 +2710,11 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> >  		 * tries to wake up @prev. So bail and do a complete
> >  		 * remote wakeup.
> >  		 */
> > -		if (ttwu_activate_remote(p, wake_flags))
> > +		if (cpu == smp_processor_id() &&
> 
> I think this needs "task_cpu(p) == smp_processor_id()". We can't trust
> "cpu", task_cpu() was called before ->on_rq check.

Isn't us holding ->pi_lock sufficient to stabilize task_cpu()? If its a
running task the initial ->state check would have failed, and thus its a
proper wakeup when we get here and thus ->pi_lock is serializing things.

> This task_cpu() looks really confusing imho, even if it is fine (afaics).
> Perhaps it makes sense to do
> 
> 	--- x/kernel/sched.c
> 	+++ x/kernel/sched.c
> 	@@ -2694,10 +2694,11 @@ try_to_wake_up(struct task_struct *p, un
> 			goto out;
> 	 
> 		success = 1; /* we're going to change ->state */
> 	-	cpu = task_cpu(p);
> 	 
> 	-	if (p->on_rq && ttwu_remote(p, wake_flags))
> 	+	if (p->on_rq && ttwu_remote(p, wake_flags)) {
> 	+		cpu = task_cpu(p); /* for ttwu_stat() */
> 			goto stat;
> 	+	}
> 	 
> 	 #ifdef CONFIG_SMP
> 		/*

Would result in the same problem as below...

> to make this more clear. Or even the patch below, I dunno.
> 
> Oleg.
> 
> --- x/kernel/sched.c
> +++ x/kernel/sched.c
> @@ -2446,13 +2446,14 @@ static void update_avg(u64 *avg, u64 sam
>  #endif
>  
>  static void
> -ttwu_stat(struct task_struct *p, int cpu, int wake_flags)
> +ttwu_stat(struct task_struct *p, int wake_flags)
>  {
>  #ifdef CONFIG_SCHEDSTATS
>  	struct rq *rq = this_rq();
>  
>  #ifdef CONFIG_SMP
>  	int this_cpu = smp_processor_id();
> +	int cpu = task_cpu(p);
>  
>  	if (cpu == this_cpu) {
>  		schedstat_inc(rq, ttwu_local);
> @@ -2694,7 +2695,6 @@ try_to_wake_up(struct task_struct *p, un
>  		goto out;
>  
>  	success = 1; /* we're going to change ->state */
> -	cpu = task_cpu(p);
>  
>  	if (p->on_rq && ttwu_remote(p, wake_flags))
>  		goto stat;
> @@ -2739,7 +2739,7 @@ try_to_wake_up(struct task_struct *p, un
>  
>  	ttwu_queue(p, cpu);

Both suggestions result in the above cpu possibly being used
uninitialized for SMP=n.

>  stat:
> -	ttwu_stat(p, cpu, wake_flags);
> +	ttwu_stat(p, wake_flags);
>  out:
>  	raw_spin_unlock_irqrestore(&p->pi_lock, flags);
>  
> @@ -2775,7 +2775,7 @@ static void try_to_wake_up_local(struct 
>  		ttwu_activate(rq, p, ENQUEUE_WAKEUP);
>  
>  	ttwu_do_wakeup(rq, p, 0);
> -	ttwu_stat(p, smp_processor_id(), 0);
> +	ttwu_stat(p, 0);
>  out:
>  	raw_spin_unlock(&p->pi_lock);
>  }
--
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/