linux-kernel - Re: [BUG] using smp_processor_id() in preemptible as suspending

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] [day] [month] [year] [list]

Message-ID: <20080228002606.GE9634@linux.vnet.ibm.com>
Date:	Wed, 27 Feb 2008 16:26:06 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Karsten Wiese <fzu@...gehoertderstaat.de>
Cc:	Dave Young <hidave.darkstar@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [BUG] using smp_processor_id() in preemptible as suspending

On Thu, Feb 28, 2008 at 12:11:48AM +0100, Karsten Wiese wrote:
> Am Mittwoch, 27. Februar 2008 schrieb Dave Young:
> > On Wed, Feb 27, 2008 at 3:45 AM, Paul E. McKenney
> > <paulmck@...ux.vnet.ibm.com> wrote:
> > > On Tue, Feb 26, 2008 at 08:33:54AM -0800, Andrew Morton wrote:
> > >  > On Tue, 26 Feb 2008 16:24:11 +0800 Dave Young <hidave.darkstar@...il.com> wrote:
> > >  >
> > >  > > I don't know whom I should mail to, could you cc the proper guy? Thanks.
> > >
> > >  Hello, Dave,
> > >
> > >  Would you be willing to try out the following (untested, might not even
> > >  compile) patch show at the very end of this message?  This assumes that
> > >  you were running with CONFIG_PREEMPT_RCU, which seems most likely based
> > >  on looking at your oops.
> > 
> > Built ok, but can't even resume now. (dark screen with cursor blinking
> > on top-left of minitor)
> 
> Dave, can you give this untested patch a try?

The second part of the patch is similar to the one I sent to Dave
earlier for testing (it worked for him, so I just now posted to LKML).
The advantage of my approach is that it retains the pair of disabled
sections, rather than merging them as yours does.

That said, as near as I can tell, your patch should work.

							Thanx, Paul

> thanks,
>       Karsten
> 
> ---
> diff --git a/kernel/rcupreempt.c b/kernel/rcupreempt.c
> index c7c5209..5a7f8fc 100644
> --- a/kernel/rcupreempt.c
> +++ b/kernel/rcupreempt.c
> @@ -878,18 +878,20 @@ void rcu_offline_cpu(int cpu)
>  	 * Otherwise rcu_barrier() will fail
>  	 */
> 
> -	spin_lock_irqsave(&rdp->lock, flags);
> +	local_irq_save(flags);
> +
> +	spin_lock(&rdp->lock);
>  	rcu_offline_cpu_enqueue(rdp->donelist, rdp->donetail, list, tail);
>  	for (i = GP_STAGES - 1; i >= 0; i--)
>  		rcu_offline_cpu_enqueue(rdp->waitlist[i], rdp->waittail[i],
>  						list, tail);
>  	rcu_offline_cpu_enqueue(rdp->nextlist, rdp->nexttail, list, tail);
> -	spin_unlock_irqrestore(&rdp->lock, flags);
> +	spin_unlock(&rdp->lock);
>  	rdp->waitlistcount = 0;
> 
>  	/* Disengage the newly dead CPU from the grace-period computation. */
> 
> -	spin_lock_irqsave(&rcu_ctrlblk.fliplock, flags);
> +	spin_lock(&rcu_ctrlblk.fliplock);
>  	rcu_check_mb(cpu);
>  	if (per_cpu(rcu_flip_flag, cpu) == rcu_flipped) {
>  		smp_mb();  /* Subsequent counter accesses must see new value */
> @@ -906,7 +908,7 @@ void rcu_offline_cpu(int cpu)
> 
>  	cpu_clear(cpu, rcu_cpu_online_map);
> 
> -	spin_unlock_irqrestore(&rcu_ctrlblk.fliplock, flags);
> +	spin_unlock(&rcu_ctrlblk.fliplock);
> 
>  	/*
>  	 * Place the removed callbacks on the current CPU's queue.
> @@ -919,11 +921,13 @@ void rcu_offline_cpu(int cpu)
>  	 */
> 
>  	rdp = RCU_DATA_ME();
> -	spin_lock_irqsave(&rdp->lock, flags);
> +	spin_lock(&rdp->lock);
>  	*rdp->nexttail = list;
>  	if (list)
>  		rdp->nexttail = tail;
> -	spin_unlock_irqrestore(&rdp->lock, flags);
> +	spin_unlock(&rdp->lock);
> +
> +	local_irq_restore(flags);
>  }
> 
>  void __devinit rcu_online_cpu(int cpu)
--
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/