On Tue, 2012-10-30 at 17:43 +, Will Newton wrote:
> Ok, well we are only concerned with C compiled code, otherwise there
> would be no calls to mcount? The only way I can think of to cause code
> to be emitted in a section of this type is to use the section
> attribute. A quick grep for __attr
On Wed, 2012-10-31 at 03:33 +0900, anish kumar wrote:
> > CPU 0 CPU 1
> >
> > data = something flags = IRQ_WORK_BUSY
> > smp_mb() (implicit with cmpxchg smp_mb()
> > on flags in claim) execute_work (sees data from CPU
> >
On Mon, 2012-10-29 at 16:27 -0400, Steven Rostedt wrote:
> plain text document attachment
> (0009-nohz-cpuset-Restart-tick-when-nohz-flag-is-cleared-o.patch)
> From: Frederic Weisbecker
>
> Issue an IPI to restart the tick on a CPU that belongs
> to a cpuset when its nohz
On Mon, 2012-10-29 at 16:27 -0400, Steven Rostedt wrote:
> plain text document attachment
> (0010-nohz-cpuset-Restart-the-tick-if-printk-needs-it.patch)
> From: Frederic Weisbecker
>
> If we are in nohz adaptive mode and printk is called, the tick is
> missing to wake up the
On Tue, 2012-10-30 at 14:46 -0400, Sasha Levin wrote:
> Switch tracing to use the new hashtable implementation. This reduces the
> amount of generic unrelated code in the tracing module.
>
> Signed-off-by: Sasha Levin
Acked-by: Steven Rostedt
-- Steve
--
To unsubscribe from thi
On Wed, 2012-10-31 at 00:51 +0100, Frederic Weisbecker wrote:
> > Probably just use irq_work for self ipis, and normal ipis for other
> > CPUs.
>
> Right. And that's one more reason why we want to know if the arch
> implements irq work with self ipis or not. If the arch can't, then we
> just don'
From: Thomas Gleixner
This uses a timer_list timer from the irq disabled guts of the idle
code. Disable it for now to prevent wreckage.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
init/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/Kcon
/kernel/projects/rt/3.4/incr/patch-3.4.15-rt25-rt26-rc1.patch.xz
Changes from 3.4.15-rt25:
---
Steven Rostedt (1):
Linux 3.4.15-rt26-rc1
Thomas Gleixner (2):
rcu: Disable RCU_FAST_NO_HZ on RT
net: netfilter: Serialize xt_write_recseq sections on RT
Watanabe (1
From: Watanabe
When the hrtimer stall detection hits the softirq is not raised.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
kernel/hrtimer.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 8b3d423..9
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index c5b71f9..02556f4 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt25
+-rt26-rc1
--
1.7.10.4
--
To unsubscribe from this
From: Thomas Gleixner
The netfilter code relies only on the implicit semantics of
local_bh_disable() for serializing wt_write_recseq sections. RT breaks
that and needs explicit serialization here.
Reported-by: Peter LaDow
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
includ
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 2470798..623b4c9 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt48
+-rt49-rc1
--
1.7.10.4
--
To unsubscribe from this
/kernel/projects/rt/3.2/incr/patch-3.2.32-rt48-rt49-rc1.patch.xz
Changes from 3.2.32-rt48:
---
Steven Rostedt (1):
Linux 3.2.32-rt49-rc1
Thomas Gleixner (2):
rcu: Disable RCU_FAST_NO_HZ on RT
net: netfilter: Serialize xt_write_recseq sections on RT
Watanabe (1
From: Watanabe
When the hrtimer stall detection hits the softirq is not raised.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
kernel/hrtimer.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index bca6928..9
From: Thomas Gleixner
This uses a timer_list timer from the irq disabled guts of the idle
code. Disable it for now to prevent wreckage.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
init/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/Kcon
From: Thomas Gleixner
The netfilter code relies only on the implicit semantics of
local_bh_disable() for serializing wt_write_recseq sections. RT breaks
that and needs explicit serialization here.
Reported-by: Peter LaDow
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
includ
From: Thomas Gleixner
The netfilter code relies only on the implicit semantics of
local_bh_disable() for serializing wt_write_recseq sections. RT breaks
that and needs explicit serialization here.
Reported-by: Peter LaDow
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
includ
From: Watanabe
When the hrtimer stall detection hits the softirq is not raised.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
kernel/hrtimer.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 7327846..8
/kernel/projects/rt/3.0/incr/patch-3.0.48-rt71-rt72-rc1.patch.xz
Changes from 3.0.48-rt71:
---
Steven Rostedt (1):
Linux 3.0.48-rt72-rc1
Thomas Gleixner (2):
rcu: Disable RCU_FAST_NO_HZ on RT
net: netfilter: Serialize xt_write_recseq sections on RT
Watanabe (1
From: Thomas Gleixner
This uses a timer_list timer from the irq disabled guts of the idle
code. Disable it for now to prevent wreckage.
Signed-off-by: Thomas Gleixner
Cc: stable...@vger.kernel.org
---
init/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/Kcon
From: Steven Rostedt
---
localversion-rt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index f38a3cc..70396d6 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt71
+-rt72-rc1
--
1.7.10.4
--
To unsubscribe from this
On Tue, 2012-10-30 at 20:33 -0400, Sasha Levin wrote:
> On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo wrote:
> > Hello,
> >
> > Just some nitpicks.
> >
> > On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
> >> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit
> >> ke
On Tue, 2012-10-30 at 18:25 -0700, Linus Torvalds wrote:
> On Tue, Oct 30, 2012 at 6:16 PM, Steven Rostedt wrote:
> >
> > ({\
> > sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits);
On Wed, 2012-10-31 at 01:36 +0100, Frederic Weisbecker wrote:
> 2012/10/30 anish kumar :
> > As I understand without the memory barrier proposed by you the situation
> > would be as below:
> > CPU 0 CPU 1
> >
> > data = something flags = IRQ_WORK_
As Tejun said, each commit needs its own change log. Never expect a
change lgo from another commit to be read for changes in this commit.
> Index: linux/kernel/events/callchain.c
> Index: linux/kernel/events/core.c
> Index: linux/kernel/printk/printk.c
> Index: linux/kernel/rcutree.c
> Index: lin
On Mon, 26 Aug 2013 10:46:38 +0900
Yoshihiro YUNOMAE wrote:
> > The --date option is used because the two machines are not in sync with
> > the trace time stamp. What the date option does, is to sync the
> > timestamp up with the gettimeofday and the output reports that. This
> > allows the two b
On Mon, 26 Aug 2013 10:48:15 +0900
Yoshihiro YUNOMAE wrote:
> >> +static int open_udp(const char *node, const char *port, int *pid,
> >> + int cpu, int pagesize, int start_port)
> >> +{
> >> + int sfd;
> >> + int num_port;
> >> +
> >> + num_port = udp_bind_a_port(start_port, &sfd
On Mon, 26 Aug 2013 10:50:33 +0900
Yoshihiro YUNOMAE wrote:
>
> 0. old server and old client
> Old servers send "tracecmd" as the first message.
> Old clients compare the first 8byte of the first message with "tracecmd".
>
> 1. new server
> - Send "tracecmd-v2" as the first message.
> - Check
On Mon, 26 Aug 2013 15:20:09 +
Christoph Lameter wrote:
> On Mon, 26 Aug 2013, Steven Rostedt wrote:
>
> > As Tejun said, each commit needs its own change log. Never expect a
> > change lgo from another commit to be read for changes in this commit.
>
> I can copy th
On Mon, 26 Aug 2013 09:29:28 -0700
"Paul E. McKenney" wrote:
> On Mon, Aug 26, 2013 at 10:58:38AM -0400, Dave Jones wrote:
> > Another day, another rcu backtrace..
> > This says rc6, but it's pretty darn close to rc7, I think it was running
> > a build from Friday.
>
> Could you please send your
On Mon, 26 Aug 2013 13:50:12 -0400
Dave Jones wrote:
>
> This was triggered as a regular user fwiw.
> I had not been running perf, or any other tracing. It was just left
> fuzzing over the weekend with no interaction at all.
So you are telling me that ftrace was enabled by a regular user? If so,
On Mon, 26 Aug 2013 14:29:07 -0400
Dave Jones wrote:
> On Mon, Aug 26, 2013 at 02:18:14PM -0400, Steven Rostedt wrote:
> > On Mon, 26 Aug 2013 13:50:12 -0400
> > Dave Jones wrote:
> > >
> > > This was triggered as a regular user fwiw.
> > >
On Tue, 27 Aug 2013 17:07:34 +0900
Yoshihiro YUNOMAE wrote:
et, but I'd like to
> add such feature to fix host/guest clock difference in the next series.
> TSC offset values can be gotten as write_tsc_offset trace event from
> kernel-3.11. (see https://lkml.org/lkml/2013/6/12/72)
> How do you thin
On Tue, 27 Aug 2013 19:23:24 +0900
Yoshihiro YUNOMAE wrote:
> OK, let me check that. Even if the old server will receive "V2", the
> server will send port numbers instead of "V2" due to the old protocol.
> In that time, the new client will disconnect from the old server and
> the restarts with t
On Tue, 27 Aug 2013 20:35:12 +0900
Masami Hiramatsu wrote:
> Hi Tom,
>
> I've reviewed and tested them and found no problem! ;)
>
> So for this series:
> Reviewed-by: Masami Hiramatsu
>
> Now, I think it is the time to push it into tracing tree
> and to be widely tested.
>
Thanks Masami for
On Mon, 26 Aug 2013 15:49:24 -0400
Dave Jones wrote:
> > Do you have /sys/kernel/debug with access permissions?
>
> Ah, yeah, that'll be it. Good catch.
>
> Sorry for the false alarm Steve ;)
Yeah, but it still does not explain how perf got started. Perf requires
a sys_perf_event_open() call
On Mon, 26 Aug 2013 01:12:02 +0530
Abhay Sachan wrote:
> Hi All,
> I have installed 3.10.6 kernel on my HP laptop. I keep getting this message
> in dmesg after a few hours of usage. I was getting the similar messages in
> stable-3.9 too.
So this is with vanilla 3.10.6 and not the -rt version?
>
On Mon, 26 Aug 2013 22:55:59 -0500
Tom Zanussi wrote:
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index b1227b9..1733ac9 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -1016,9 +1016,184 @@ extern void trace_event_enable_cmd_record(bool
> enable);
> exter
On Tue, 27 Aug 2013 14:40:13 -0500
Tom Zanussi wrote:
> @@ -415,9 +429,14 @@ static void unreg_event_syscall_enter(struct
> ftrace_event_file *file,
> return;
> mutex_lock(&syscall_trace_lock);
> tr->sys_refcount_enter--;
> - clear_bit(num, tr->enabled_enter_syscall
On Tue, 27 Aug 2013 14:40:13 -0500
Tom Zanussi wrote:
return;
> - if (!test_bit(syscall_nr, tr->enabled_enter_syscalls))
> +
> + /* Here we're inside the tp handler's rcu_read_lock (__DO_TRACE()) */
> + ftrace_file = rcu_dereference_raw(tr->enter_syscall_files[syscall_
On Tue, 27 Aug 2013 14:40:14 -0500
Tom Zanussi wrote:
> +
> + if (copy_from_user(buf, ubuf, cnt)) {
> + free_page((unsigned long) buf);
> + return -EFAULT;
> + }
> + buf[cnt] = '\0';
> + strim(buf);
> +
> + mutex_lock(&event_mutex);
> + event_file =
On Tue, 27 Aug 2013 14:40:14 -0500
Tom Zanussi wrote:
> Signed-off-by: Tom Zanussi
> Idea-by: Steve Rostedt
> ---
> include/linux/ftrace_event.h| 13 +-
> include/trace/ftrace.h | 4 +
> kernel/trace/Makefile | 1 +
> kernel/trace/trace.h
On Tue, 27 Aug 2013 18:29:06 -0500
Tom Zanussi wrote:
> On Tue, 2013-08-27 at 16:01 -0400, Steven Rostedt wrote:
> > On Tue, 27 Aug 2013 14:40:13 -0500
> > Tom Zanussi wrote:
> >
> > return;
> > > - if (!test_bit(syscall_nr, tr->enabled_e
On Wed, 28 Aug 2013 10:19:37 +0200
Peter Zijlstra wrote:
> > An unlock followed by a lock needs to act like a full barrier, but there
> > is no requirement that a lock or unlock taken separately act like a
> > full barrier.
>
> But that is already a property of the acquisition/release barrier.
On Wed, 28 Aug 2013 15:05:29 +0200
Peter Zijlstra wrote:
> On Wed, Aug 28, 2013 at 08:59:57AM -0400, Steven Rostedt wrote:
> > On Wed, 28 Aug 2013 10:19:37 +0200
> > Peter Zijlstra wrote:
>
> > Spin locks only prevent leaks out of the critical section. It does not
>
On Tue, 27 Aug 2013 23:46:27 -0400
Dave Jones wrote:
> WARNING: CPU: 0 PID: 8961 at kernel/trace/ftrace.c:1640
> __ftrace_hash_rec_update.part.37+0x20a/0x240()
> Modules linked in: bridge stp fuse hidp bnep rfcomm nfnetlink ipt_ULOG
> scsi_transport_iscsi can_bcm nfc caif_socket caif af_802154
On Wed, 28 Aug 2013 09:54:08 -0400
Steven Rostedt wrote:
>
> OK, this is a hint. The __unregister_ftrace_function returned an error
> code, and called ftrace_shutdown(). This is an error path that is not
> tested much. So perhaps you did find another place that can cause the
> ac
Dave,
BTW, is there a way to run trinity on a subset of syscalls. Basically,
I would like to run it on just the perf code, and nothing else. I have
a feeling that the bug you see is not caused by other operations
happening (although it could be), but from just out of order perf
calls. If I can rep
On Wed, 28 Aug 2013 20:30:17 +0900
Yoshihiro YUNOMAE wrote:
> (2013/08/27 22:05), Steven Rostedt wrote:
> > On Tue, 27 Aug 2013 19:23:24 +0900
> > Yoshihiro YUNOMAE wrote:
> >
> >> OK, let me check that. Even if the old server will receive "V2", the
>
On Wed, 28 Aug 2013 09:58:33 -0400
Steven Rostedt wrote:
> I'll take that back. The ftrace_shutdown() is called on success, thus
> this is a normal path. I have to find out what perf is doing. Do you
> have any clue to what calls are being made to perf?
This may be the error path
On Tue, 27 Aug 2013 14:40:19 -0500
Tom Zanussi wrote:
> enum {
> FILTER_OTHER = 0,
> diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> index 326ba32..6c701c3 100644
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -412,13 +412,15 @@ static inline notrace int
On Wed, 28 Aug 2013 12:50:36 -0400 (EDT)
Vince Weaver wrote:
> On Wed, 28 Aug 2013, Dave Jones wrote:
> > Quite often just rerunning that last syscall that caused the oops/warn
> > isn't sufficient to trigger an issue. (Though it may be for this specific
> > bug that may not be the case..)
> >
>
On Tue, 27 Aug 2013 14:40:20 -0500
Tom Zanussi wrote:
> extern int filter_current_check_discard(struct ring_buffer *buffer,
> @@ -336,6 +350,20 @@ extern enum event_trigger_type
> event_triggers_call(struct ftrace_event_file *fil
> extern void event_triggers_post_call(struct ftrace_event_fi
On Wed, 28 Aug 2013 14:29:02 -0400
> > >
> > > diff --git a/kernel/trace/trace_event_perf.c
> b/kernel/trace/trace_event_perf.c
> > > index 80c36bc..05167bb 100644
> > > --- a/kernel/trace/trace_event_perf.c
> > > +++ b/kernel/trace/trace_event_perf.c
> > > @@ -306,6 +306,7 @@ static
On Mon, 26 Aug 2013 20:44:37 +
Christoph Lameter wrote:
> __get_cpu_var() is used for multiple purposes in the kernel source. One of
> them is
> address calculation via the form &__get_cpu_var(x). This calculates the
> address for
> the instance of the percpu variable of the current process
On Tue, 27 Aug 2013 14:40:12 -0500
Tom Zanussi wrote:
> Tom Zanussi (10):
> tracing: Add support for SOFT_DISABLE to syscall events
> tracing: add basic event trigger framework
> tracing: add 'traceon' and 'traceoff' event trigger commands
> tracing: add 'snapshot' event trigger command
On Thu, Aug 29, 2013 at 04:57:43PM +, Christoph Lameter wrote:
>
> We could add a this_cpu variant that would be used in the cases we do
> not want preemption checks? There should not be too many but it will
> mean a whole lot of new definitions in percpu.h.
Let's get away from underscore
On Tue, 2013-10-01 at 00:20 -0400, Dave Jones wrote:
> It seems like trace-cmd needs to be run as root. all hell will break loose if
> trinity gets root privs.
Then run this:
trace-cmd record -e syscalls -B trinity su davej -c 'trinity '
-- Steve
--
To unsubscribe from this list: send the li
On Wed, 2013-10-02 at 10:16 -0400, Dave Jones wrote:
> On Tue, Oct 01, 2013 at 08:28:51AM -0400, Steven Rostedt wrote:
> > On Tue, 2013-10-01 at 00:20 -0400, Dave Jones wrote:
> >
> > > It seems like trace-cmd needs to be run as root. all hell will break
> loose
On Wed, 2013-10-02 at 14:57 -0400, Dave Jones wrote:
> And that's the cause. I wonder what was being opened.
> Do you happen to have a trinity-child log for that thread ?
Thanks for the update. This definitely looks like the bug, and explains
a lot. I'll look into this, as I'm currently at a conf
On Fri, 04 Oct 2013 15:40:29 +0200
Jan Kiszka wrote:
> Ping. While my other patch of that time was merged, this one didn't make
> it yet. Any open issues?
Hmm, no. Not sure how I missed this one. Probably because it didn't
have the 2/2 patch format and I thought there was only one patch?
I'll
ince we now have two need_resched states; trace the two so we can
> > observe discrepancies.
> >
> > Cc: Steven Rostedt
> > Signed-off-by: Peter Zijlstra
>
> Steve, if you're done conferencing.. any objections?
>
Taking a quick look, my only objection so far is
[0.00] RIP 0x46
>
> Bisection identified this as the problem commit.
>
> 9c85f3bdf400665eecf62658a9106501f6a77a13 is the first bad commit
> commit 9c85f3bdf400665eecf62658a9106501f6a77a13
> Author: Steven Rostedt
> Date: Thu Jan 26 18:38:07 2012 -0500
>
>
On Fri, 4 Oct 2013 17:16:18 +0200
Peter Zijlstra wrote:
> Documentation section
>
> Ah, you missed the preemption series?
Yeah, I've seen them, just haven't looked at them too deeply yet.
>
> 1a338ac32ca6 sched, x86: Optimize the preempt_schedule() call
> c2daa3bed53a sched, x86: Provide a pe
On Fri, 4 Oct 2013 17:28:26 +0200
Peter Zijlstra wrote:
> On Fri, Oct 04, 2013 at 10:53:42AM -0400, Steven Rostedt wrote:
> > In other words, what does these flags in the trace actually mean?
> > Probably need to add comments in the code and/or update the
> > Documentation
On Fri, 4 Oct 2013 12:12:25 -0700
Linus Torvalds wrote:
> - together with using a few inline functions, suddenly the "indirect"
> jumps through this type descriptor end up actually being nice direct
> compile-time constants: iow, they get turned into direct jumps.
As all the rcu_synchronizatio
when
> p->nr_cpus_allowed == 1 at the beginning of the function. This makes
> the latter p->nr_cpus_allowed > 1 check redundant and can be removed.
>
> Signed-off-by: Shawn Bohrer
Reviewed-by: Steven Rostedt
-- Steve
> ---
> kernel/sched/rt.c | 3 +--
> 1 file
On Fri, 4 Oct 2013 14:39:46 -0700
Andi Kleen wrote:
> From: Andi Kleen
>
> UPROBES need the perf events code, so add a dependency
> from PERF_EVENTS to UPROBES.
Can you please be a bit more specific on what uprobes requires of perf?
That is, what part of the perf events code is needed, and wh
itectures don't check for this.
But they should.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Steven Rostedt
> Cc: Jason Baron
> Cc: Peter Zijlstra
> Cc: Eric Dumazet
> Cc: "David S. Miller"
> Cc: x...@kern
uggy TI redrivers.
Schemmel Hans-Christoph (1):
USB: Blacklisted Cinterion's PLxx WWAN Interface
Sergio Aguirre (1):
xhci-mem: init list heads at the beginning of init
Srivatsa S. Bhat (1):
CPU hotplug: provide a generic helper to disable/enable CPU hotplug
Stephen M. Cameron (1
On Wed, 2013-07-10 at 11:52 +0200, Peter Zijlstra wrote:
> Fun.. :-) we trace __local_bh_enable() and hit a ftrace callback between
> telling lockdep we enabled softirqs and actually doing so.
>
> I'm just a tad confused by the trace; it says we go:
> lock_is_held()
> check_flags()
>
> Loo
On Wed, 2013-07-10 at 14:42 +0200, Peter Zijlstra wrote:
> but but but preempt_disable_notrace() isn't an rcu_read_lock().. You can only
> do that for rcu_sched.
Right. And not even rcu_sched is safe, as function tracing can trace
functions out of rcu scope. That's why I had to add that code to d
Dear RT Folks,
I'm pleased to announce the 3.6.11.6-rt38 stable release.
This release is just an update to the new stable 3.6.11.6 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-
Dear RT Folks,
I'm pleased to announce the 3.4.52-rt67 stable release.
This release is just an update to the new stable 3.4.52 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.g
Dear RT Folks,
I'm pleased to announce the 3.0.85-rt113 stable release.
This release is just an update to the new stable 3.0.85 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.
Dear RT Folks,
I'm pleased to announce the 3.2.48-rt69 stable release.
This release is just an update to the new stable 3.2.48 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.g
On Wed, 2013-07-10 at 13:12 -0400, Paul Gortmaker wrote:
> [[RFC][PATCH RT 6/6] vtime: Convert vtime_seqlock into raw_spinlock_t and
> seqcount combo] On 26/06/2013 (Wed 15:28) Steven Rostedt wrote:
>
> > The vtime seqlock needs to be taken in true interrupt context on -rt.
On Wed, 2013-07-10 at 14:36 -0700, H. Peter Anvin wrote:
> On 07/10/2013 02:31 PM, Jiri Kosina wrote:
> >
> > If any CPU instruction execution would collide with the patching,
> > it'd be trapped by the int3 breakpoint and redirected to the provided
> > "handler" (which would typically mean just s
On Wed, 2013-07-10 at 23:31 +0200, Jiri Kosina wrote:
> Changes:
>
> v1 -> v2:
> + fixed kerneldoc
> + fixed checkpatch errors (reported by Borislav)
>
> arch/x86/include/asm/alternative.h |1 +
> arch/x86/kernel/alternative.c | 101
>
> kernel
On Thu, 2013-07-11 at 02:04 +0200, Jiri Kosina wrote:
> I even have preliminary (completely untested) patch, but would like to
> have this merged/acked in the first round before proceeding with porting
> ftrace to the new interface.
>
> > Also, I wonder if its worth batching up updates. For exa
On Thu, 2013-07-11 at 09:31 -0700, H. Peter Anvin wrote:
> The current code assumes that one of the two code sequences is a NOP,
> and therefore that jumping over the region is legal. This does not
> allow for transitioning one active code sequence to another.
Correct, and I think we should keep
On Thu, 2013-07-11 at 08:31 +0800, Chen Gang wrote:
> Like other trace_selftest_startup_*, trace_selftest_startup_function()
> and trace_selftest_startup_function_graph() need in normal section, or
> may cause section mismatch.
>
> The related warnings:
>
> LD kernel/trace/built-in.o
>
On Thu, 2013-07-11 at 18:42 +0200, Peter Zijlstra wrote:
> I'm afraid this is going to be hard to create and hard to keep correct :/
That's the nature of tracing functions ;-)
>
> Other than that, a function tracer environment that is safer to use might be
> useful for other people as well.
No
On Thu, 2013-07-11 at 12:55 -0400, Steven Rostedt wrote:
> >
> > Other than that, a function tracer environment that is safer to use might be
> > useful for other people as well.
>
> Not sure how to make the environment safe, as the main purpose of the
> function trac
On Thu, 2013-07-11 at 21:43 +0200, Jiri Kosina wrote:
> OTOH we apparently don't need the one after the text_poke() below, as
> syncing the cores just after patching the first byte afterwards provides
> safe enough guard (at least according to hpa's words back in 2010 :) ).
Right, but I'm paran
On Thu, 2013-07-11 at 21:23 +0200, Jiri Kosina wrote:
> > Thus you would need to do something like:
>
> Yup, I have been looking at the ftrace implementation and came to this
> conclusion; thanks for confirmation.
> That's exactly why I wanted to postpone converting ftrace before agreement
> on
On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
> Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
> use '__init', so not waste memory keeping them around ?
Yeah, they should all be set to __init, but that's pretty low on the
totem poll, as distros don't enable selftests
On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote:
> > For .10 I had to start making a list of "shit that's broken that there's
> > an outstanding patch for" and nagging people to send them week after week.
> > Every time I reported a new bug I'd hit, I'd have to explain I wasn't
> > ru
On Thu, 2013-07-11 at 20:50 -0400, Theodore Ts'o wrote:
> Maybe the pendulum has swung too far in the direction of holding back
> changes and trying to avoid the risk of introducing regressions;
> perhaps this would be a good topic to discuss at the Kernel Summit.
Bah, I sent out a similar email
you have a missing asterisk.
See Documentation/kernel-doc-nano-HOWTO.txt for more info.
But other than that, you can add my:
Reviewed-by: Steven Rostedt
-- Steve
> + * In contrary to text_poke_smp(), we completely avoid stop_machine() here,
> + * and achieve the synchronization using int3 b
On Fri, 2013-07-12 at 00:31 +0200, Jiri Kosina wrote:
> On Thu, 11 Jul 2013, H. Peter Anvin wrote:
>
> > > synchronization after replacing "all but first" instructions should not
> > > be necessary (on Intel hardware), as the syncing after the subsequent
> > > patching of the first byte provides e
is the one being updated
>
> arch/x86/kernel/jump_label.c | 16 ++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
Reviewed-by: Steven Rostedt
-- Steve
> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
> index 2889b3d..460f5d9 100644
&g
On Thu, 2013-07-11 at 17:33 -0700, Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 08:24:33PM -0400, Paul Gortmaker wrote:
> > On Thu, Jul 11, 2013 at 6:11 PM, Greg Kroah-Hartman
> > wrote:
> > > This is the start of the stable review cycle for the 3.4.53 release.
> > > There are 11 patches in
On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
> On 07/12/2013 09:41 AM, Steven Rostedt wrote:
> > On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
> >
> >> > Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
> >> > use &#x
On Fri, 2013-07-12 at 08:22 -0700, Linus Torvalds wrote:
> Listen to yourself. In fact, there is a damn good solution": don't
> mark crap for stable, and don't send crap to me after -rc4.
>
I tend to hold things off after -rc4 because you scare me more than Greg
does ;-)
Actually, as I conside
On Fri, 2013-07-12 at 08:55 -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 8:47 AM, Steven Rostedt wrote:
> >
> > I tend to hold things off after -rc4 because you scare me more than Greg
> > does ;-)
>
> Have you guys *seen* Greg? The guy is a freakish giant.
On Fri, 2013-07-12 at 10:28 -0700, Greg Kroah-Hartman wrote:
> Yes, this requires you to remember to do this after it hits Linus's
> tree, so you could do like David does for networking, and keep a
> seperate tree to send to me specifically for stable patches. I think he
> uses patchwork, but I k
On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote:
> On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt wrote:
> >
> > Perhaps just make a separate stable branch, where you cherry-pick the
> > specific patch using the -x option. Adds a "(cherry picked from
> &
On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
> They can be useful for "local" notes (they can be very powerful for
> certain workflows), but they won't be pulled and pushed by me.
Perhaps notes can be used as that reminder to send to stable. Tag a
commit with a note, and have some aut
On Fri, 2013-07-12 at 15:35 -0400, Theodore Ts'o wrote:
> So the problem is that maintainers are lazy. They don't want to go
> back for bug fixes that have "proven" themselves, and even if they
> aren't critical bug fixes, they are things which a distro maintainer
> or a stable kernel user might
601 - 700 of 19470 matches
Mail list logo
