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]
Message-ID: <20170503220950.45cf3c6f@grimm.local.home>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ