linux-kernel - Re: [patch 16/23] dynticks: core

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:	Sat, 30 Sep 2006 17:41:29 +0530
From:	Dipankar Sarma <dipankar@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Jim Gettys <jg@...top.org>, John Stultz <johnstul@...ibm.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: [patch 16/23] dynticks: core

On Sat, Sep 30, 2006 at 01:44:56AM -0700, Andrew Morton wrote:
> On Fri, 29 Sep 2006 23:58:35 -0000
> Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > From: Ingo Molnar <mingo@...e.hu>
> > 
> > dynticks core code.
> > 
> > Add idling-stats to the cpu base (to be used to optimize power
> > management decisions), add the scheduler tick and its stop/restart
> > functions, and the jiffies-update function to be called when an irq
> > context hits the idle context.
> > 
> 
> I worry that we're making this feature optional.
> > +	/*
> > +	 * RCU normally depends on the timer IRQ kicking completion
> > +	 * in every tick. We have to do this here now:
> > +	 */
> > +	if (rcu_pending(cpu)) {
> > +		/*
> > +		 * We are in quiescent state, so advance callbacks:
> > +		 */
> > +		rcu_advance_callbacks(cpu, 1);
> > +		local_irq_enable(); <----------------- Here
> > +		local_bh_disable();
> > +		rcu_process_callbacks(0);
> > +		local_bh_enable();
> > +	}
> > +
> > +	local_irq_restore(flags);
> > +
> > +	return need_resched();
> > +}
> 
> Are the RCU guys OK with this?

What prevents more RCU callbacks getting queued up by an
irq after irqs are enabled (marked Here) ? This seems racy.
The s390 implementation is correct - there we back out
if RCU is pending. Also, one call
to rcu_process_callbacks() doesn't guarantee that all
the RCUs are processed. They can be rate limited.

Thanks
Dipankar
-
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/