All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	mingo@redhat.com, a.p.zijlstra@chello.nl, peterz@infradead.org,
	anton@redhat.com, rostedt@goodmis.org, tglx@linutronix.de,
	oleg@redhat.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, hpa@zytor.com, jkenisto@us.ibm.com,
	andi@firstfloor.org, hch@infradead.org, ananth@in.ibm.com,
	vda.linux@googlemail.com, masami.hiramatsu.pt@hitachi.com,
	acme@infradead.org, srikar@linux.vnet.ibm.com,
	roland@hack.frob.com, mingo@elte.hu,
	linux-tip-commits@vger.kernel.org
Subject: Re: [tip:perf/uprobes] uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints
Date: Mon, 21 May 2012 19:27:00 -0700	[thread overview]
Message-ID: <20120521192700.71bfda5f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120522111618.ca91892dc6027f9a4251235e@canb.auug.org.au>

On Tue, 22 May 2012 11:16:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> On Mon, 21 May 2012 15:13:23 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Mon, 21 May 2012 15:00:28 -0700
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > > On Mon, May 21, 2012 at 2:37 PM, Andrew Morton
> > > <akpm@linux-foundation.org> wrote:
> > > >
> > > > hm, we seem to have conflicting commits between mainline and linux-next.
> > > > During the merge window. __Again. __Nobody knows why this happens.
> > > 
> > > I didn't have my trivial cleanup branches in linux-next, I'm afraid.
> > 
> > Well, it's a broader issue than that.  I often see a large number of
> > rejects when syncing mainline with linux-next during the merge window. 
> > Right now:
> 
> Some of that is because your patch series is based on the end of
> linux-next and part way through the merge window only some of that has
> been merged by Linus.  Also some of it gets rebased before Linus is asked
> to pull (a real pain) - there hasn't been much of that (yet) this merge
> window (but its early days :-().  Also, sometimes Linus' merge
> resolutions are different to mine.
> 
> I have been meaning to talk to you about basing the majority of your
> patch series on Linus' tree.  This would give it mush greater stability
> and would make the merge resolution my problem (and Linus', of course).

Confused.  None of those conflicts have anything to do with the -mm
patches: the only trees involved there are mainline and
trees-in-next-other-than-mm.

> There will be bits that may need to be based on other work in linux-next,
> but I suspect that it is not very much.

Well, there are a number of reasons why I base off linux-next.  To see
whether others have merged patches which I have merged (and, sometimes,
missed later fixes to them).  Explicit fixes against -next material. 
To get visibility into upcoming merge problems.  And so that I and
others test -next too.

Basing -mm on next is never a problem (for me).  What is a problem is
the mess which happens when people merge things into mainline which are
(I assume) either slightly different from what they merged in -next or
which never were in -next at all.

That's guessing - it's a long time since I sat down and worked out exactly
what is causing this.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	mingo@redhat.com, a.p.zijlstra@chello.nl, peterz@infradead.org,
	anton@redhat.com, rostedt@goodmis.org, tglx@linutronix.de,
	oleg@redhat.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, hpa@zytor.com, jkenisto@us.ibm.com,
	andi@firstfloor.org, hch@infradead.org, ananth@in.ibm.com,
	vda.linux@googlemail.com, masami.hiramatsu.pt@hitachi.com,
	acme@infradead.org, srikar@linux.vnet.ibm.com,
	roland@hack.frob.com, mingo@elte.hu,
	linux-tip-commits@vger.kernel.org
Subject: Re: [tip:perf/uprobes] uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints
Date: Mon, 21 May 2012 19:27:00 -0700	[thread overview]
Message-ID: <20120521192700.71bfda5f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120522111618.ca91892dc6027f9a4251235e@canb.auug.org.au>

On Tue, 22 May 2012 11:16:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> On Mon, 21 May 2012 15:13:23 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Mon, 21 May 2012 15:00:28 -0700
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > > On Mon, May 21, 2012 at 2:37 PM, Andrew Morton
> > > <akpm@linux-foundation.org> wrote:
> > > >
> > > > hm, we seem to have conflicting commits between mainline and linux-next.
> > > > During the merge window. __Again. __Nobody knows why this happens.
> > > 
> > > I didn't have my trivial cleanup branches in linux-next, I'm afraid.
> > 
> > Well, it's a broader issue than that.  I often see a large number of
> > rejects when syncing mainline with linux-next during the merge window. 
> > Right now:
> 
> Some of that is because your patch series is based on the end of
> linux-next and part way through the merge window only some of that has
> been merged by Linus.  Also some of it gets rebased before Linus is asked
> to pull (a real pain) - there hasn't been much of that (yet) this merge
> window (but its early days :-().  Also, sometimes Linus' merge
> resolutions are different to mine.
> 
> I have been meaning to talk to you about basing the majority of your
> patch series on Linus' tree.  This would give it mush greater stability
> and would make the merge resolution my problem (and Linus', of course).

Confused.  None of those conflicts have anything to do with the -mm
patches: the only trees involved there are mainline and
trees-in-next-other-than-mm.

> There will be bits that may need to be based on other work in linux-next,
> but I suspect that it is not very much.

Well, there are a number of reasons why I base off linux-next.  To see
whether others have merged patches which I have merged (and, sometimes,
missed later fixes to them).  Explicit fixes against -next material. 
To get visibility into upcoming merge problems.  And so that I and
others test -next too.

Basing -mm on next is never a problem (for me).  What is a problem is
the mess which happens when people merge things into mainline which are
(I assume) either slightly different from what they merged in -next or
which never were in -next at all.

That's guessing - it's a long time since I sat down and worked out exactly
what is causing this.

  reply	other threads:[~2012-05-22  2:25 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02 14:18 [PATCH v10 3.3-rc2 0/9] Uprobes patchset with perf probe support Srikar Dronamraju
2012-02-02 14:18 ` Srikar Dronamraju
2012-02-02 14:18 ` [PATCH v10 3.3-rc2 1/9] uprobes: Install and remove breakpoints Srikar Dronamraju
2012-02-02 14:18   ` Srikar Dronamraju
2012-02-03 12:01   ` Masami Hiramatsu
2012-02-03 12:01     ` Masami Hiramatsu
2012-02-07 17:17   ` Srikar Dronamraju
2012-02-07 17:17     ` Srikar Dronamraju
2012-02-08  9:40     ` Denys Vlasenko
2012-02-08  9:40       ` Denys Vlasenko
2012-02-08  9:40       ` Srikar Dronamraju
2012-02-08  9:40         ` Srikar Dronamraju
2012-02-09  1:27       ` Masami Hiramatsu
2012-02-09  1:27         ` Masami Hiramatsu
2012-02-09  6:37         ` Srikar Dronamraju
2012-02-09  6:37           ` Srikar Dronamraju
2012-02-09  7:53           ` Ingo Molnar
2012-02-09  7:53             ` Ingo Molnar
2012-02-09  8:14             ` Srikar Dronamraju
2012-02-09  8:14               ` Srikar Dronamraju
2012-02-09  8:17           ` Masami Hiramatsu
2012-02-09  8:17             ` Masami Hiramatsu
2012-02-09  8:27             ` Srikar Dronamraju
2012-02-09  8:27               ` Srikar Dronamraju
2012-02-08 14:08     ` Srikar Dronamraju
2012-02-08 14:08       ` Srikar Dronamraju
2012-02-09  9:26       ` [PATCH v10 take 3 " Srikar Dronamraju
2012-02-09  9:26         ` Srikar Dronamraju
2012-02-17  9:58         ` [tip:perf/uprobes] uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints tip-bot for Srikar Dronamraju
2012-02-17  9:58           ` tip-bot for Srikar Dronamraju
2012-05-21 21:37           ` Andrew Morton
2012-05-21 21:37             ` Andrew Morton
2012-05-21 22:00             ` Linus Torvalds
2012-05-21 22:00               ` Linus Torvalds
2012-05-21 22:13               ` Andrew Morton
2012-05-21 22:13                 ` Andrew Morton
2012-05-22  1:16                 ` Stephen Rothwell
2012-05-22  2:27                   ` Andrew Morton [this message]
2012-05-22  2:27                     ` Andrew Morton
2012-05-22  6:50                     ` Stephen Rothwell
2012-05-23  0:37                 ` Stephen Rothwell
2012-05-22  1:10               ` Stephen Rothwell
2012-05-22  6:01               ` Srikar Dronamraju
2012-05-22  6:01                 ` Srikar Dronamraju
2012-05-22  8:05             ` Srikar Dronamraju
2012-05-22  8:05               ` Srikar Dronamraju
2012-02-02 14:19 ` [PATCH v10 3.3-rc2 2/9] uprobes: handle breakpoint and signal step exception Srikar Dronamraju
2012-02-02 14:19   ` Srikar Dronamraju
2012-02-02 14:19 ` [PATCH v10 3.3-rc2 3/9] uprobes: slot allocation Srikar Dronamraju
2012-02-02 14:19   ` Srikar Dronamraju
2012-02-02 14:19 ` [PATCH v10 3.3-rc2 4/9] uprobes: counter to optimize probe hits Srikar Dronamraju
2012-02-02 14:19   ` Srikar Dronamraju
2012-02-02 14:19 ` [PATCH v10 3.3-rc2 5/9] tracing: modify is_delete, is_return from ints to bool Srikar Dronamraju
2012-02-02 14:19   ` Srikar Dronamraju
2012-02-02 14:20 ` [PATCH v10 3.3-rc2 6/9] tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2012-02-02 14:20   ` Srikar Dronamraju
2012-02-02 14:20 ` [PATCH v10 3.3-rc2 7/9] tracing: uprobes trace_event interface Srikar Dronamraju
2012-02-02 14:20   ` Srikar Dronamraju
2012-02-02 14:20 ` [PATCH v10 3.3-rc2 8/9] perf: rename target_module to target Srikar Dronamraju
2012-02-02 14:20   ` Srikar Dronamraju
2012-02-07 19:33   ` [tip:perf/core] perf probe: Rename " tip-bot for Srikar Dronamraju
2012-02-07 19:33     ` tip-bot for Srikar Dronamraju
2012-02-02 14:20 ` [PATCH v10 3.3-rc2 9/9] perf: perf interface for uprobes Srikar Dronamraju
2012-02-02 14:20   ` Srikar Dronamraju

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120521192700.71bfda5f.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=ananth@in.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=anton@redhat.com \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jkenisto@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roland@hack.frob.com \
    --cc=rostedt@goodmis.org \
    --cc=sfr@canb.auug.org.au \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.