linux-kernel - Re: Question about usage of RCU in the input layer

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 21 Mar 2009 11:58:11 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Eric Dumazet <dada1@...mosbay.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Arjan van de Ven <arjan@...radead.org>,
	dipankar@...ibm.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Question about usage of RCU in the input layer

On Sat, Mar 21, 2009 at 10:13:38AM +0100, Eric Dumazet wrote:
> Dmitry Torokhov a écrit :
> > On Thursday 19 March 2009 20:20:32 Arjan van de Ven wrote:
> >>> I don't claim to understand the code in question, so it is entirely
> >>> possible that the following is irrelevant.  But one other reason for
> >>> synchronize_rcu() is:
> >>>
> >>> 1.    Make change.
> >>>
> >>> 2.    synchronize_rcu()
> >>>
> >>> 3.    Now you are guaranteed that all CPUs/tasks/whatever
> >>> currently running either are not messing with you on the one hand, or
> >>>       have seen the change on the other.
> >> ok so this is for the case where someone is already iterating the list.
> >>
> >> I don't see anything in the code that assumes this..
> > 
> > This is something that input core guarantees to its users: by the time
> > input core calls hander->start() or, in its absence, by the time
> > input_register_handle() returns, events from input drivers will be
> > passed into the handle being registered, i.e. the presence of the
> > new item in the list is noticed by all CPUs.
> > 
> > Now, it is possible to stop using RCU primitives in the input core
> > but I think that you'd want to figure out why synchronize_rcu()
> > takes so long first, otheriwse you may find another "abuser"
> > down the road.
> > 
> 
> If a cpu does a loop, it nearly impossible that synchronize_rcu() can
> be fast.
> 
> We had same problem in ksoftirqd(), where I had to add a call
> to rcu_qsctr_inc() to unblock other threads blocked in synchronize_rcu()
> 
> http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64ca5ab913f1594ef316556e65f5eae63ff50cee
> 
> If a driver does a loop with no call to scheduler, it might have same problem

And hopefully Arjan's promised bootgraph will give us some insights
as to what might be holding up the grace period.

							Thanx, Paul
--
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/