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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 6 Nov 2015 13:37:48 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [GIT PULL] tracing: Updates for 4.4

On Fri, Nov 6, 2015 at 6:10 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Most of the changes are clean ups and small fixes. Some of them have
> stable tags to them. I searched through my INBOX just as the merge window
> opened and found lots of patches to pull. I ran them through all my tests
> and they were in linux-next for a few days.

Clearly they got zero actual testing, though.

I get several very big and ugly warnings about scheduler tracing:

  kernel/trace/trace_events.c: In function ‘__ftrace_clear_event_pids’:
  kernel/trace/trace_events.c:579:32: warning: passing argument 1 of
‘unregister_trace_sched_switch’ from incompatible pointer type
[-Wincompatible-pointer-types]
    unregister_trace_sched_switch(event_filter_pid_sched_switch_probe_pre, tr);
                                  ^
  In file included from kernel/trace/trace_events.c:25:0:
  include/trace/events/sched.h:124:1095: note: expected ‘void (*)(void
*, bool,  struct task_struct *, struct task_struct *) {aka void
(*)(void *, _Bool,  struct task_struct *, struct task_struct *)}’ but
argument is of type ‘void (*)(void *, struct task_struct *, struct
task_struct *)’

which clearly can't work, and is due to the new "bool preempt"
argument in scheduler tracing.

That *should* have shown up in linux-next, and you *should* have been
aware of it, and in turn let me know about it. Yes, yes, I notice
these things on my own, but I also expect that maintainers look out
for these things, especially when they were involved on both sides, so
it shouldn't have taken them - and this me - by surprise.

But something clearly failed in that whole process.

This is why we do *not* do some last-minute "let's just look through
my mailbox as the merge window is opening" crap.

I've done the merge, and I have it fixed up in my tree, but I'm
annoyed enough that I'm considering just unpulling. You *knew* about
this, because you are marked as having reviewed that commit
c73464b1c843 ("sched/core: Fix trace_sched_switch()") that added the
preempt argument.

So where did this all fail? Nobody ever looked at the warnings from
linux-next? Or it wasn't even in linux-next long enough to really ever
trigger?

I very much suspect that "look through my INBOX as the merge window
opened" is the real problem here. That is *not* how the merge window
works, and you damn well should know it.

                     Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ