linux-kernel - Re: [GIT PULL] tracing: Updates for v4.12

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 3 May 2017 22:09:50 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] tracing: Updates for v4.12

On Wed, 3 May 2017 18:59:05 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, May 2, 2017 at 4:41 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> >  This will conflict with changes I have already sent to you. They may
> >  not be so trivial to fix. I merged my urgent branch when pushing to
> >  linux-next. You can look at how I resolved the conflicts in my
> >  "for-next" branch, specifically sha1: f96d18dee6f09486b944b75f6151d36381f396b5  
> 
> Hmm. My merge resolution is different, but I think I did it right.
> 
> Yours does
> 
>         ret = alloc_snapshot(&global_trace);
> 
> and I think it should be
> 
>         ret = alloc_snapshot(tr);

No you are right. Damn, I'm upset at myself that I missed it. Another
good reason to have you do the merge and not the subsystem
maintainers ;-)

> 
> but you should double-check it. I only looked at the code, I didn't
> actually *test* anything.

I have a couple of small patches I'm about to test and send to you
later while the merge window is open. Would you be fine if I just add
them on top of your merge commit? That would kill two birds with one
test.

> 
> (There's a few other differences, but they are just ordering of the
> function declarations).

I'll have to look at that (haven't looked at your merge commit yet).
Because there were two functions that made more sense to go together,
and the merge put the odd ball one in the middle.

> 
> Btw, I'd prefer to *not* see the full patch in the pull request if
> it's this big. For small stuff, sure. For a multi-thousand-line patch?
> I'm not reading those in a mail-reader anyway.

It's part of my script that prepares the pull request. I could remove
it. I kept it there because it also shows others the code that I am
asking to be changed. It's just my way of being open. But I'm not too
hard set to keep it. If you prefer, I can stop doing that.

-- Steve