Re: linux-next: question about the luto-misc tree
On Sun, Dec 28, 2014 at 07:33:43AM -0800, Andy Lutomirski wrote: > On Dec 25, 2014 5:33 PM, "Stephen Rothwell" wrote: > > > > Hi Andy, > > > > On Mon, 22 Dec 2014 11:16:56 -0800 Andy Lutomirski > wrote: > > > > > > I'm re-adding the branch, since 3.19-rc1 is out, the change appears to > > > still exist as-is in your tree, and it merges cleanly and builds in > > > the latest -next for me. Let me know if this will be problematic for > > > any reason. > > > > So, now we have a problem because Paul has rebased a whole set of > > commits that you have in your tree. Commits c6dc129cf2d1 to > > f58d100f65ae in your tree Paul has rebased on top of v3.19-rc1. If you > > are going to base your tree on (part of) Paul's tree, then Paul has to > > agree to not rebase that part of his tree or you have to keep a watch > > on his tree and rebase you tree on top of those rebased commits. > > Really, the first should happen. > > Are there any scripts out there that can do this for me? > > Paul, when do you expect to be done rebasing? Or, even better, when do you > expect to send all of this to -tip? If the latter will be reasonably soon, > I can just wait for that. I believe that I have it where it will live from here on out, namely at 734d16801349 (rcu: Make rcu_nmi_enter() handle nesting) in -rcu. The only reason I would move it is if it turned out to be fatally buggy, but given your testing the odds of this happening are hopefully quite low. (Famous last words!) Thaxnx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
On Fri, Dec 26, 2014 at 9:02 AM, Paul E. McKenney wrote: > On Fri, Dec 26, 2014 at 12:33:36PM +1100, Stephen Rothwell wrote: >> Hi Andy, >> >> On Mon, 22 Dec 2014 11:16:56 -0800 Andy Lutomirski >> wrote: >> > >> > I'm re-adding the branch, since 3.19-rc1 is out, the change appears to >> > still exist as-is in your tree, and it merges cleanly and builds in >> > the latest -next for me. Let me know if this will be problematic for >> > any reason. >> >> So, now we have a problem because Paul has rebased a whole set of >> commits that you have in your tree. Commits c6dc129cf2d1 to >> f58d100f65ae in your tree Paul has rebased on top of v3.19-rc1. If you >> are going to base your tree on (part of) Paul's tree, then Paul has to >> agree to not rebase that part of his tree or you have to keep a watch >> on his tree and rebase you tree on top of those rebased commits. >> Really, the first should happen. > > Apologies, Stephen -- I do seem to be your problem child at the moment! > > The desried commit is "rcu: Make rcu_nmi_enter() handle nesting", correct? > Once confirmed or corrected, I will place this commit at the base of my > 3.20 tree, which will rebase it one last time, then avoid rebasing it > in the future, at least assuming no more bugs in that particular commit. > Sorry for responding out of order and in HTML. I just got back from a couple of days in the wilderness, and I'm catching up out of order. I've dropped this from my tree for now. Paul, when you've done the final rebase, can you let me know? Thanks, Andy > Thanx, Paul > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
On Fri, Dec 26, 2014 at 12:33:36PM +1100, Stephen Rothwell wrote: > Hi Andy, > > On Mon, 22 Dec 2014 11:16:56 -0800 Andy Lutomirski > wrote: > > > > I'm re-adding the branch, since 3.19-rc1 is out, the change appears to > > still exist as-is in your tree, and it merges cleanly and builds in > > the latest -next for me. Let me know if this will be problematic for > > any reason. > > So, now we have a problem because Paul has rebased a whole set of > commits that you have in your tree. Commits c6dc129cf2d1 to > f58d100f65ae in your tree Paul has rebased on top of v3.19-rc1. If you > are going to base your tree on (part of) Paul's tree, then Paul has to > agree to not rebase that part of his tree or you have to keep a watch > on his tree and rebase you tree on top of those rebased commits. > Really, the first should happen. Apologies, Stephen -- I do seem to be your problem child at the moment! The desried commit is "rcu: Make rcu_nmi_enter() handle nesting", correct? Once confirmed or corrected, I will place this commit at the base of my 3.20 tree, which will rebase it one last time, then avoid rebasing it in the future, at least assuming no more bugs in that particular commit. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
Hi Andy, On Mon, 22 Dec 2014 11:16:56 -0800 Andy Lutomirski wrote: > > I'm re-adding the branch, since 3.19-rc1 is out, the change appears to > still exist as-is in your tree, and it merges cleanly and builds in > the latest -next for me. Let me know if this will be problematic for > any reason. So, now we have a problem because Paul has rebased a whole set of commits that you have in your tree. Commits c6dc129cf2d1 to f58d100f65ae in your tree Paul has rebased on top of v3.19-rc1. If you are going to base your tree on (part of) Paul's tree, then Paul has to agree to not rebase that part of his tree or you have to keep a watch on his tree and rebase you tree on top of those rebased commits. Really, the first should happen. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpYBUG4LQSO7.pgp Description: OpenPGP digital signature
Re: linux-next: question about the luto-misc tree
On Sun, Dec 14, 2014 at 10:17 AM, Paul E. McKenney wrote: > On Sun, Dec 14, 2014 at 09:41:04AM -0800, Andy Lutomirski wrote: >> On Sun, Dec 14, 2014 at 9:37 AM, Paul E. McKenney >> wrote: >> > On Sun, Dec 14, 2014 at 08:29:33AM -0800, Andy Lutomirski wrote: >> >> On Sun, Dec 14, 2014 at 4:03 AM, Paul E. McKenney >> >> wrote: >> >> > On Sat, Dec 13, 2014 at 11:26:36PM -0800, Andy Lutomirski wrote: >> >> >> On Dec 13, 2014 10:58 PM, "Stephen Rothwell" >> >> >> wrote: >> >> >> > >> >> >> > Hi Andy, >> >> >> > >> >> >> > The luto-misc tree seems to have a whole series of commits in it that >> >> >> > have just bee removed from the rcu tree ... You really have to be >> >> >> > very >> >> >> > careful if you base your work on a tree that is regularly rebased. >> >> >> >> >> >> Hmm. They were there a couple days ago. Paul, what should I do about >> >> >> this? I only need the one NMI nesting change for the stuff in >> >> >> luto/next. >> >> >> >> >> >> > I also wonder if the other commits in that tree are destined for >> >> >> > v3.19? If they are for v3.20, then they should not be in linux-next >> >> >> > until after v3.19-rc1 has been released. >> >> >> >> >> >> They're for 3.20. I'll drop the whole series from the next branch for >> >> >> now. >> >> > >> >> > You mean the NMI nesting change below, correct? One approach would be >> >> > to include the branch rcu/dev from my -rcu tree. Would that work for >> >> > you? >> >> >> >> That would work. >> >> >> >> The problem is that, if you rebase again and I don't notice, then >> >> it'll generate a pile of conflicts. Is there someway that I can flag >> >> my next tree as depending on a certain commi existing in another tree >> >> so that the scripts that generate linux-next will ignore it if the >> >> base commit goes away? >> > >> > The commits would still stick around because I keep date-encoded branches. >> > But just to make things easier, I created a andy.2014.11.21a branch that >> > points to the current commit and will stay there. Please let me know how >> > it goes. >> >> That's the same commit that's in rcu/dev and was in luto/next, I >> think. Is the issue just that you pulled the whole thing from >> whichever linux-rcu branch is in -next, but I still had it, so it >> caused a problem? > > I still have the commit. All I did was move the rcu/next branch that > Stephen pulls from. > >> In any case, I'll wait for 3.19-rc1 before re-adding any of this. > > That does sound simpler, as I will make this commit available to -next > at that point. ;-) > I'm re-adding the branch, since 3.19-rc1 is out, the change appears to still exist as-is in your tree, and it merges cleanly and builds in the latest -next for me. Let me know if this will be problematic for any reason. Thanks, Andy > Thanx, Paul > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
On Sun, Dec 14, 2014 at 09:41:04AM -0800, Andy Lutomirski wrote: > On Sun, Dec 14, 2014 at 9:37 AM, Paul E. McKenney > wrote: > > On Sun, Dec 14, 2014 at 08:29:33AM -0800, Andy Lutomirski wrote: > >> On Sun, Dec 14, 2014 at 4:03 AM, Paul E. McKenney > >> wrote: > >> > On Sat, Dec 13, 2014 at 11:26:36PM -0800, Andy Lutomirski wrote: > >> >> On Dec 13, 2014 10:58 PM, "Stephen Rothwell" > >> >> wrote: > >> >> > > >> >> > Hi Andy, > >> >> > > >> >> > The luto-misc tree seems to have a whole series of commits in it that > >> >> > have just bee removed from the rcu tree ... You really have to be > >> >> > very > >> >> > careful if you base your work on a tree that is regularly rebased. > >> >> > >> >> Hmm. They were there a couple days ago. Paul, what should I do about > >> >> this? I only need the one NMI nesting change for the stuff in > >> >> luto/next. > >> >> > >> >> > I also wonder if the other commits in that tree are destined for > >> >> > v3.19? If they are for v3.20, then they should not be in linux-next > >> >> > until after v3.19-rc1 has been released. > >> >> > >> >> They're for 3.20. I'll drop the whole series from the next branch for > >> >> now. > >> > > >> > You mean the NMI nesting change below, correct? One approach would be > >> > to include the branch rcu/dev from my -rcu tree. Would that work for > >> > you? > >> > >> That would work. > >> > >> The problem is that, if you rebase again and I don't notice, then > >> it'll generate a pile of conflicts. Is there someway that I can flag > >> my next tree as depending on a certain commi existing in another tree > >> so that the scripts that generate linux-next will ignore it if the > >> base commit goes away? > > > > The commits would still stick around because I keep date-encoded branches. > > But just to make things easier, I created a andy.2014.11.21a branch that > > points to the current commit and will stay there. Please let me know how > > it goes. > > That's the same commit that's in rcu/dev and was in luto/next, I > think. Is the issue just that you pulled the whole thing from > whichever linux-rcu branch is in -next, but I still had it, so it > caused a problem? I still have the commit. All I did was move the rcu/next branch that Stephen pulls from. > In any case, I'll wait for 3.19-rc1 before re-adding any of this. That does sound simpler, as I will make this commit available to -next at that point. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
On Sun, Dec 14, 2014 at 9:37 AM, Paul E. McKenney wrote: > On Sun, Dec 14, 2014 at 08:29:33AM -0800, Andy Lutomirski wrote: >> On Sun, Dec 14, 2014 at 4:03 AM, Paul E. McKenney >> wrote: >> > On Sat, Dec 13, 2014 at 11:26:36PM -0800, Andy Lutomirski wrote: >> >> On Dec 13, 2014 10:58 PM, "Stephen Rothwell" >> >> wrote: >> >> > >> >> > Hi Andy, >> >> > >> >> > The luto-misc tree seems to have a whole series of commits in it that >> >> > have just bee removed from the rcu tree ... You really have to be very >> >> > careful if you base your work on a tree that is regularly rebased. >> >> >> >> Hmm. They were there a couple days ago. Paul, what should I do about >> >> this? I only need the one NMI nesting change for the stuff in >> >> luto/next. >> >> >> >> > I also wonder if the other commits in that tree are destined for >> >> > v3.19? If they are for v3.20, then they should not be in linux-next >> >> > until after v3.19-rc1 has been released. >> >> >> >> They're for 3.20. I'll drop the whole series from the next branch for >> >> now. >> > >> > You mean the NMI nesting change below, correct? One approach would be >> > to include the branch rcu/dev from my -rcu tree. Would that work for you? >> >> That would work. >> >> The problem is that, if you rebase again and I don't notice, then >> it'll generate a pile of conflicts. Is there someway that I can flag >> my next tree as depending on a certain commi existing in another tree >> so that the scripts that generate linux-next will ignore it if the >> base commit goes away? > > The commits would still stick around because I keep date-encoded branches. > But just to make things easier, I created a andy.2014.11.21a branch that > points to the current commit and will stay there. Please let me know how > it goes. > That's the same commit that's in rcu/dev and was in luto/next, I think. Is the issue just that you pulled the whole thing from whichever linux-rcu branch is in -next, but I still had it, so it caused a problem? In any case, I'll wait for 3.19-rc1 before re-adding any of this. --Andy > Thanx, Paul > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
On Sun, Dec 14, 2014 at 08:29:33AM -0800, Andy Lutomirski wrote: > On Sun, Dec 14, 2014 at 4:03 AM, Paul E. McKenney > wrote: > > On Sat, Dec 13, 2014 at 11:26:36PM -0800, Andy Lutomirski wrote: > >> On Dec 13, 2014 10:58 PM, "Stephen Rothwell" wrote: > >> > > >> > Hi Andy, > >> > > >> > The luto-misc tree seems to have a whole series of commits in it that > >> > have just bee removed from the rcu tree ... You really have to be very > >> > careful if you base your work on a tree that is regularly rebased. > >> > >> Hmm. They were there a couple days ago. Paul, what should I do about > >> this? I only need the one NMI nesting change for the stuff in > >> luto/next. > >> > >> > I also wonder if the other commits in that tree are destined for > >> > v3.19? If they are for v3.20, then they should not be in linux-next > >> > until after v3.19-rc1 has been released. > >> > >> They're for 3.20. I'll drop the whole series from the next branch for now. > > > > You mean the NMI nesting change below, correct? One approach would be > > to include the branch rcu/dev from my -rcu tree. Would that work for you? > > That would work. > > The problem is that, if you rebase again and I don't notice, then > it'll generate a pile of conflicts. Is there someway that I can flag > my next tree as depending on a certain commi existing in another tree > so that the scripts that generate linux-next will ignore it if the > base commit goes away? The commits would still stick around because I keep date-encoded branches. But just to make things easier, I created a andy.2014.11.21a branch that points to the current commit and will stay there. Please let me know how it goes. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
On Sun, Dec 14, 2014 at 4:03 AM, Paul E. McKenney wrote: > On Sat, Dec 13, 2014 at 11:26:36PM -0800, Andy Lutomirski wrote: >> On Dec 13, 2014 10:58 PM, "Stephen Rothwell" wrote: >> > >> > Hi Andy, >> > >> > The luto-misc tree seems to have a whole series of commits in it that >> > have just bee removed from the rcu tree ... You really have to be very >> > careful if you base your work on a tree that is regularly rebased. >> >> Hmm. They were there a couple days ago. Paul, what should I do about >> this? I only need the one NMI nesting change for the stuff in >> luto/next. >> >> > I also wonder if the other commits in that tree are destined for >> > v3.19? If they are for v3.20, then they should not be in linux-next >> > until after v3.19-rc1 has been released. >> >> They're for 3.20. I'll drop the whole series from the next branch for now. > > You mean the NMI nesting change below, correct? One approach would be > to include the branch rcu/dev from my -rcu tree. Would that work for you? > That would work. The problem is that, if you rebase again and I don't notice, then it'll generate a pile of conflicts. Is there someway that I can flag my next tree as depending on a certain commi existing in another tree so that the scripts that generate linux-next will ignore it if the base commit goes away? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
Hi Andy, On Sat, 13 Dec 2014 23:26:36 -0800 Andy Lutomirski wrote: > > On Dec 13, 2014 10:58 PM, "Stephen Rothwell" wrote: > > > > The luto-misc tree seems to have a whole series of commits in it that > > have just bee removed from the rcu tree ... You really have to be very > > careful if you base your work on a tree that is regularly rebased. > > Hmm. They were there a couple days ago. Paul, what should I do about > this? I only need the one NMI nesting change for the stuff in > luto/next. One of them was causing a problem and (I think) the rest were for v3.20 and so Paul reset his tree. > > I also wonder if the other commits in that tree are destined for > > v3.19? If they are for v3.20, then they should not be in linux-next > > until after v3.19-rc1 has been released. > > They're for 3.20. I'll drop the whole series from the next branch for now. Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpUIy_a7CiQw.pgp Description: OpenPGP digital signature
Re: linux-next: question about the luto-misc tree
On Sat, Dec 13, 2014 at 11:26:36PM -0800, Andy Lutomirski wrote:
> On Dec 13, 2014 10:58 PM, "Stephen Rothwell" wrote:
> >
> > Hi Andy,
> >
> > The luto-misc tree seems to have a whole series of commits in it that
> > have just bee removed from the rcu tree ... You really have to be very
> > careful if you base your work on a tree that is regularly rebased.
>
> Hmm. They were there a couple days ago. Paul, what should I do about
> this? I only need the one NMI nesting change for the stuff in
> luto/next.
>
> > I also wonder if the other commits in that tree are destined for
> > v3.19? If they are for v3.20, then they should not be in linux-next
> > until after v3.19-rc1 has been released.
>
> They're for 3.20. I'll drop the whole series from the next branch for now.
You mean the NMI nesting change below, correct? One approach would be
to include the branch rcu/dev from my -rcu tree. Would that work for you?
Thanx, Paul
rcu: Make rcu_nmi_enter() handle nesting
The x86 architecture has multiple types of NMI-like interrupts: real
NMIs, machine checks, and, for some values of NMI-like, debugging
and breakpoint interrupts. These interrupts can nest inside each
other. Andy Lutomirski is adding RCU support to these interrupts,
so rcu_nmi_enter() and rcu_nmi_exit() must now correctly handle nesting.
This commit therefore introduces nesting, using a clever NMI-coordination
algorithm suggested by Andy. The trick is to atomically increment
->dynticks (if needed) before manipulating ->dynticks_nmi_nesting on entry
(and, accordingly, after on exit). In addition, ->dynticks_nmi_nesting
is incremented by one if ->dynticks was incremented and by two otherwise.
This means that when rcu_nmi_exit() sees ->dynticks_nmi_nesting equal
to one, it knows that ->dynticks must be atomically incremented.
This NMI-coordination algorithms has been validated by the following
Promela model:
/*
* Promela model for Andy Lutomirski's suggested change to rcu_nmi_enter()
* that allows nesting.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, you can access it online at
* http://www.gnu.org/licenses/gpl-2.0.html.
*
* Copyright IBM Corporation, 2014
*
* Author: Paul E. McKenney
*/
byte dynticks_nmi_nesting = 0;
byte dynticks = 0;
/*
* Promela verision of rcu_nmi_enter().
*/
inline rcu_nmi_enter()
{
byte incby;
byte tmp;
incby = BUSY_INCBY;
assert(dynticks_nmi_nesting >= 0);
if
:: (dynticks & 1) == 0 ->
atomic {
dynticks = dynticks + 1;
}
assert((dynticks & 1) == 1);
incby = 1;
:: else ->
skip;
fi;
tmp = dynticks_nmi_nesting;
tmp = tmp + incby;
dynticks_nmi_nesting = tmp;
assert(dynticks_nmi_nesting >= 1);
}
/*
* Promela verision of rcu_nmi_exit().
*/
inline rcu_nmi_exit()
{
byte tmp;
assert(dynticks_nmi_nesting > 0);
assert((dynticks & 1) != 0);
if
:: dynticks_nmi_nesting != 1 ->
tmp = dynticks_nmi_nesting;
tmp = tmp - BUSY_INCBY;
dynticks_nmi_nesting = tmp;
:: else ->
dynticks_nmi_nesting = 0;
atomic {
dynticks = dynticks + 1;
}
assert((dynticks & 1) == 0);
fi;
}
/*
* Base-level NMI runs non-atomically. Crudely emulates process-level
* dynticks-idle entry/exit.
*/
proctype base_NMI()
{
byte busy;
busy = 0;
do
:: /* Emulate base-level dynticks and not. */
if
:: 1 -> atomic {
dynticks = dynticks + 1;
}
busy = 1;
:: 1 -> skip;
fi;
/* Verify that we only sometimes have base-level dynticks. */
Re: linux-next: question about the luto-misc tree
On Dec 13, 2014 10:58 PM, "Stephen Rothwell" wrote: > > Hi Andy, > > The luto-misc tree seems to have a whole series of commits in it that > have just bee removed from the rcu tree ... You really have to be very > careful if you base your work on a tree that is regularly rebased. Hmm. They were there a couple days ago. Paul, what should I do about this? I only need the one NMI nesting change for the stuff in luto/next. > > I also wonder if the other commits in that tree are destined for > v3.19? If they are for v3.20, then they should not be in linux-next > until after v3.19-rc1 has been released. They're for 3.20. I'll drop the whole series from the next branch for now. --Andy > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
