| Message ID | 1367280494.30667.38.camel@gandalf.local.home (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 2013-04-29 at 20:08 -0400, Steven Rostedt wrote: > On Mon, 2013-04-29 at 14:42 -0700, Linus Torvalds wrote: > > On Mon, Apr 29, 2013 at 2:01 PM, Linus Torvalds > > <torvalds@linux-foundation.org> wrote: > > > > > > There's just too much confusion here for me to touch anything at all, > > > so please fix things up. > > > > Oh, and you might as well check that I resolved the conflicts in the > > trace pull correctly while you're at it. They looked pretty obvious, > > and it compiles for me, but .. > > Almost. > BTW, what's the preferred method for this. I already posted a lot of work to linux-next when I found bugs that required going into your tree. I backported the fixes knowing that it will cause conflicts when you merge. IIRC, you stated that you don't mind doing conflict resolutions yourself, so I did not try to fix it a head of time, as the conflicts were rather minor. Should I have merged your tree and done the conflict resolutions myself, or was it OK to do what I did, and let you do the conflict resolution and send you any fixes that needed to be done afterward? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2013-04-29 at 20:08 -0400, Steven Rostedt wrote: > I'll also run my full ftrace test suite on your latest kernel, and see > if it finds anything else. > With the fix I sent, everything passed. Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 29, 2013 at 5:17 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > > BTW, what's the preferred method for this. I already posted a lot of > work to linux-next when I found bugs that required going into your tree. > I backported the fixes knowing that it will cause conflicts when you > merge. > > IIRC, you stated that you don't mind doing conflict resolutions > yourself, so I did not try to fix it a head of time, as the conflicts > were rather minor. > > Should I have merged your tree and done the conflict resolutions myself, > or was it OK to do what I did, and let you do the conflict resolution > and send you any fixes that needed to be done afterward? You did the right thing. In general, if you know there will be conflicts, it's nice if you mention then in the pull request, but for simple stuff like this it's really not a big deal. The fact that I screwed up and then missed a "!" when editing it all is embarrassing, but it wasn't because the conflict was really *complicated*, it was just stupid editing error. If the conflicts are really complex, at some point I really enjoy getting a "here's a pre-merged branch if you prefer it", and if people send that, I still tend to do the merge myself, but then I often just compare against the pre-merged one afterwards to verify. But that's actually extra work, so I'd suggest doing that only for things that really warrant it. It's generally a bad thing if it happens, because it means that we had some bad workflow and people stepped on each others toes (or we had unlucky backports etc that ended up being in the same area as much more work). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 581630a..ae6fa2d 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -904,7 +904,7 @@ update_max_tr_single(struct trace_array *tr, struct task_struct *tsk, int cpu) return; WARN_ON_ONCE(!irqs_disabled()); - if (tr->allocated_snapshot) { + if (!tr->allocated_snapshot) { /* Only the nop tracer should hit this when disabling */ WARN_ON_ONCE(tr->current_trace != &nop_trace); return;