On Thu, Oct 08, 2015 at 05:10:21PM -0700, Paul E. McKenney wrote:
> > Note that there are rnp->lock acquires without the extra barrier though,
> > so you seem somewhat inconsistent with your own rule.
> >
> > See for example:
> >
> > rcu_dump_cpu_stacks()
> > print_other_cpu_stall()
> >
On Thu, Oct 08, 2015 at 07:12:03PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 08, 2015 at 08:33:51AM -0700, Paul E. McKenney wrote:
>
> > > > o CPU B therefore moves up the tree, acquiring the parent
> > > > rcu_node structures' ->lock. In so doing, it forces full
> > > > or
On Thu, Oct 08, 2015 at 07:12:03PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 08, 2015 at 08:33:51AM -0700, Paul E. McKenney wrote:
>
> > > > o CPU B therefore moves up the tree, acquiring the parent
> > > > rcu_node structures' ->lock. In so doing, it forces full
> > > > or
On Thu, Oct 08, 2015 at 08:33:51AM -0700, Paul E. McKenney wrote:
> > > o CPU B therefore moves up the tree, acquiring the parent
> > > rcu_node structures' ->lock. In so doing, it forces full
> > > ordering against all prior RCU read-side critical sections
> > > of all CPUs corresponding t
On Thu, Oct 08, 2015 at 11:49:33AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2015 at 09:48:58AM -0700, Paul E. McKenney wrote:
>
> > > Some implementation choice requires this barrier upgrade -- and in
> > > another email I suggest its the whole tree thing, we need to firmly
> > > establish t
On Wed, Oct 07, 2015 at 08:18:29AM -0700, Paul E. McKenney wrote:
> Actually, this would be quite good. "Premature abstraction is the
> root of all evil" and all that, but this abstraction is anything but
> premature. My thought would be to have it against commit cd58087c9cee
> ("Merge branches
On Wed, Oct 07, 2015 at 09:48:58AM -0700, Paul E. McKenney wrote:
> > Some implementation choice requires this barrier upgrade -- and in
> > another email I suggest its the whole tree thing, we need to firmly
> > establish the state of one level before propagating the state up etc.
> >
> > Now I'
On Wed, Oct 07, 2015 at 04:40:24PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2015 at 07:33:25AM -0700, Paul E. McKenney wrote:
> > > I'm sure you know what that means, but I've no clue ;-) That is, I
> > > wouldn't know where to start looking in the RCU implementation to verify
> > > the barri
On Wed, Oct 07, 2015 at 01:50:46PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2015 at 01:01:20PM +0200, Peter Zijlstra wrote:
>
> > That again doesn't explain which UNLOCKs with non-matching lock values
> > it pairs with and what particular ordering is important here.
>
> So after staring at
On Wed, Oct 07, 2015 at 01:01:20PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2015 at 08:42:05AM +, Mathieu Desnoyers wrote:
> > - On Oct 7, 2015, at 3:51 AM, Peter Zijlstra pet...@infradead.org wrote:
> >
> > > On Tue, Oct 06, 2015 at 01:58:50PM -0700, Paul E. McKenney wrote:
> > >> O
On Wed, Oct 07, 2015 at 07:33:25AM -0700, Paul E. McKenney wrote:
> > I'm sure you know what that means, but I've no clue ;-) That is, I
> > wouldn't know where to start looking in the RCU implementation to verify
> > the barrier is either needed or sufficient. Unless you mean _everywhere_
> > :-)
On Wed, Oct 07, 2015 at 09:51:14AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 06, 2015 at 01:58:50PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 06, 2015 at 10:29:37PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 06, 2015 at 09:29:21AM -0700, Paul E. McKenney wrote:
> > > > +static void __mayb
On Wed, Oct 07, 2015 at 10:21:33PM +0800, Fengguang Wu wrote:
> On Wed, Oct 07, 2015 at 03:55:29PM +0200, Peter Zijlstra wrote:
> > How about not building when there's no "^Signed-off-by:" at all?
>
> That's a good idea: no need to test quick demo-of-idea patches.
>
> > Even private build fails f
On Wed, Oct 07, 2015 at 03:55:29PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2015 at 09:44:32PM +0800, Fengguang Wu wrote:
>
> > > Wu, is there a tag one can include to ward off this patch sucking robot
> > > prematurely?
> >
> > Yes. The best way may be to push the patches to a git tree kno
On Wed, Oct 07, 2015 at 09:44:32PM +0800, Fengguang Wu wrote:
> > Wu, is there a tag one can include to ward off this patch sucking robot
> > prematurely?
>
> Yes. The best way may be to push the patches to a git tree known to
> 0day robot:
>
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lk
On Wed, Oct 07, 2015 at 02:17:51PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2015 at 08:11:01PM +0800, kbuild test robot wrote:
> > Hi Peter,
> >
> > [auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please
> > ignore]
>
> So much punishment for not having compiled my prot
On Wed, Oct 07, 2015 at 08:11:01PM +0800, kbuild test robot wrote:
> Hi Peter,
>
> [auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please
> ignore]
So much punishment for not having compiled my proto patch :/
Wu, is there a tag one can include to ward off this patch sucking
Hi Peter,
[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please
ignore]
config: i386-randconfig-x007-201540 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
kernel/rc
Hi Peter,
[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please
ignore]
config: x86_64-randconfig-x010-201540 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In fi
Hi Peter,
[auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore]
config: i386-randconfig-x004-201540 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/rcu/tre
On Wed, Oct 07, 2015 at 01:50:46PM +0200, Peter Zijlstra wrote:
> @@ -1512,10 +1554,8 @@ rcu_start_future_gp(struct rcu_node *rnp, struct
> rcu_data *rdp,
>* hold it, acquire the root rcu_node structure's lock in order to
>* start one (if needed).
>*/
> - if (rnp != rnp
On Wed, Oct 07, 2015 at 01:01:20PM +0200, Peter Zijlstra wrote:
> That again doesn't explain which UNLOCKs with non-matching lock values
> it pairs with and what particular ordering is important here.
So after staring at that stuff for a while I came up with the following.
Does this make sense, o
On Wed, Oct 07, 2015 at 08:42:05AM +, Mathieu Desnoyers wrote:
> - On Oct 7, 2015, at 3:51 AM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Tue, Oct 06, 2015 at 01:58:50PM -0700, Paul E. McKenney wrote:
> >> On Tue, Oct 06, 2015 at 10:29:37PM +0200, Peter Zijlstra wrote:
> >> > On T
- On Oct 7, 2015, at 3:51 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Oct 06, 2015 at 01:58:50PM -0700, Paul E. McKenney wrote:
>> On Tue, Oct 06, 2015 at 10:29:37PM +0200, Peter Zijlstra wrote:
>> > On Tue, Oct 06, 2015 at 09:29:21AM -0700, Paul E. McKenney wrote:
>> > > +static
On Tue, Oct 06, 2015 at 01:58:50PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 06, 2015 at 10:29:37PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 06, 2015 at 09:29:21AM -0700, Paul E. McKenney wrote:
> > > +static void __maybe_unused rcu_report_exp_rnp(struct rcu_state *rsp,
> > > +
On Tue, Oct 06, 2015 at 10:29:37PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 06, 2015 at 09:29:21AM -0700, Paul E. McKenney wrote:
> > +static void __maybe_unused rcu_report_exp_rnp(struct rcu_state *rsp,
> > + struct rcu_node *rnp, bool wake)
> > +{
> > +
On Tue, Oct 06, 2015 at 09:29:21AM -0700, Paul E. McKenney wrote:
> +static void __maybe_unused rcu_report_exp_rnp(struct rcu_state *rsp,
> + struct rcu_node *rnp, bool wake)
> +{
> + unsigned long flags;
> + unsigned long mask;
> +
> + raw_spin
This is a nearly pure code-movement commit, moving rcu_report_exp_rnp(),
sync_rcu_preempt_exp_done(), and rcu_preempted_readers_exp() so
that later commits can make synchronize_sched_expedited() use them.
The non-code-movement portion of this commit tags rcu_report_exp_rnp()
as __maybe_unused to av
28 matches
Mail list logo
