On Wed, Mar 02, 2016 at 11:18:23AM +0100, Peter Zijlstra wrote:
> On Wed, Mar 02, 2016 at 02:37:18PM +0800, Boqun Feng wrote:
> > I come up with something you may not like ;-) , which is taking the
> > strings of the expressions, for example:
>
> Heh, cute. Better than nothing I suppose.
It would
On Wed, Mar 02, 2016 at 02:37:18PM +0800, Boqun Feng wrote:
> I come up with something you may not like ;-) , which is taking the
> strings of the expressions, for example:
Heh, cute. Better than nothing I suppose.
On Tue, Mar 01, 2016 at 11:01:34AM +0100, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 10:57:07AM +0100, Peter Zijlstra wrote:
> > On Tue, Mar 01, 2016 at 05:32:42PM +0800, Boqun Feng wrote:
> > > > One could for example allow something like:
> > > >
> > > > rcu_read_lock();
> > > >
On Tue, Mar 01, 2016 at 10:57:07AM +0100, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 05:32:42PM +0800, Boqun Feng wrote:
> > > One could for example allow something like:
> > >
> > > rcu_read_lock();
> > > rcu_annotate(&var->field);
> > >
> > > foo();
> > >
> > > rcu_read_unlock();
On Tue, Mar 01, 2016 at 05:32:42PM +0800, Boqun Feng wrote:
> > One could for example allow something like:
> >
> > rcu_read_lock();
> > rcu_annotate(&var->field);
> >
> > foo();
> >
> > rcu_read_unlock();
> >
> > As an alternative to the syntax suggested by Ingo. This would all
On Mon, Feb 29, 2016 at 01:43:18PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 29, 2016 at 09:12:20AM +0800, Boqun Feng wrote:
>
> > The problem is:
> >
> > Currently there is no way to know which rcu_dereference() and its
> > friends a rcu_read_lock() or one of its friends is protecting. And
> >
On Mon, Feb 29, 2016 at 09:12:20AM +0800, Boqun Feng wrote:
> The problem is:
>
> Currently there is no way to know which rcu_dereference() and its
> friends a rcu_read_lock() or one of its friends is protecting. And
> the lack of such information is a pain for kernel developers and
> reviewers t
On Fri, Feb 26, 2016 at 12:25:21PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 26, 2016 at 11:06:27AM +0800, Boqun Feng wrote:
> > On Thu, Feb 25, 2016 at 07:37:24AM -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 25, 2016 at 03:32:43PM +0100, Peter Zijlstra wrote:
> > > > On Tue, Feb 16, 2016 at 0
On Fri, Feb 26, 2016 at 11:06:27AM +0800, Boqun Feng wrote:
> On Thu, Feb 25, 2016 at 07:37:24AM -0800, Paul E. McKenney wrote:
> > On Thu, Feb 25, 2016 at 03:32:43PM +0100, Peter Zijlstra wrote:
> > > On Tue, Feb 16, 2016 at 01:57:39PM +0800, Boqun Feng wrote:
> > > > As a characteristic of RCU, r
On Thu, Feb 25, 2016 at 07:37:24AM -0800, Paul E. McKenney wrote:
> On Thu, Feb 25, 2016 at 03:32:43PM +0100, Peter Zijlstra wrote:
> > On Tue, Feb 16, 2016 at 01:57:39PM +0800, Boqun Feng wrote:
> > > As a characteristic of RCU, read-side critical sections have a very
> > > loose connection with r
On Thu, Feb 25, 2016 at 03:32:43PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 16, 2016 at 01:57:39PM +0800, Boqun Feng wrote:
> > As a characteristic of RCU, read-side critical sections have a very
> > loose connection with rcu_dereference()s, which is you can only be sure
> > about an rcu_derefere
On Tue, Feb 16, 2016 at 01:57:39PM +0800, Boqun Feng wrote:
> As a characteristic of RCU, read-side critical sections have a very
> loose connection with rcu_dereference()s, which is you can only be sure
> about an rcu_dereference() might be called in some read-side critical
> section, but if code
Hi all,
This is the v2 for RCU_LOCKED_ACCESS.
Link of v1: http://article.gmane.org/gmane.linux.kernel/2143674
Changes since v1:
* Define newly introduced irq_context helpers as macros when
lockdep doesn't trace irq_context, because these helpers will be
quite simple then a
13 matches
Mail list logo
