On Wed, 18 Jun 2014 23:12:48 +0200 (CEST)
Jiri Kosina wrote:
> > I believe that this was what Steven was suggesting, though by using
> > tracing.
>
> My understanding was that Steven is suggesting using trace_printk() from
> NMI.
Not quite. I was suggesting using the ftrace ring buffer. It
On Wed, Jun 18, 2014 at 11:32:53PM +0200, Jiri Kosina wrote:
> On Wed, 18 Jun 2014, Paul E. McKenney wrote:
>
> > > I agree that it might work nicely for RCU stall detector indeed. I was
> > > looking for solution that'd work nicely both for RCU and for sysrq-l
> > > (where we can't rely on
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
> > I agree that it might work nicely for RCU stall detector indeed. I was
> > looking for solution that'd work nicely both for RCU and for sysrq-l
> > (where we can't rely on processess being stuck in any way).
>
> Agreed. And if some more
On Wed, Jun 18, 2014 at 11:12:48PM +0200, Jiri Kosina wrote:
> On Wed, 18 Jun 2014, Paul E. McKenney wrote:
>
> > > > /* Complain about tasks blocking the grace period. */
> > > > @@ -1044,8 +1041,7 @@ static void print_cpu_stall(struct rcu_state *rsp)
> > > > pr_cont(" (t=%lu
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
> > > /* Complain about tasks blocking the grace period. */
> > > @@ -1044,8 +1041,7 @@ static void print_cpu_stall(struct rcu_state *rsp)
> > > pr_cont(" (t=%lu jiffies g=%ld c=%ld q=%lu)\n",
> > > jiffies - rsp->gp_start,
> > >
On Wed, Jun 18, 2014 at 10:36:10PM +0200, Jiri Kosina wrote:
> On Wed, 18 Jun 2014, Paul E. McKenney wrote:
>
> > OK, unconditional non-use of NMIs is even easier. ;-)
> >
> > Something like the following.
> >
> > Thanx, Paul
> >
> >
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
> OK, unconditional non-use of NMIs is even easier. ;-)
>
> Something like the following.
>
> Thanx, Paul
>
>
>
> rcu:
On Wed, Jun 18, 2014 at 12:38:37PM -0400, Steven Rostedt wrote:
> On Wed, 18 Jun 2014 09:21:17 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Jun 18, 2014 at 05:58:40AM -1000, Linus Torvalds wrote:
> > > On Jun 18, 2014 4:36 AM, "Paul E. McKenney"
> > > wrote:
> > > >
> > > > I could easily
On Wed, 18 Jun 2014 09:21:17 -0700
"Paul E. McKenney" wrote:
> On Wed, Jun 18, 2014 at 05:58:40AM -1000, Linus Torvalds wrote:
> > On Jun 18, 2014 4:36 AM, "Paul E. McKenney"
> > wrote:
> > >
> > > I could easily add an option to RCU to allow people to tell it not to
> > > use NMIs to dump the
On Wed, Jun 18, 2014 at 05:58:40AM -1000, Linus Torvalds wrote:
> On Jun 18, 2014 4:36 AM, "Paul E. McKenney"
> wrote:
> >
> > I could easily add an option to RCU to allow people to tell it not to
> > use NMIs to dump the stack.
>
> I don't think it should be an "option".
>
> We should stop
On Wed, Jun 18, 2014 at 04:53:14PM +0200, Jiri Kosina wrote:
> On Wed, 18 Jun 2014, Paul E. McKenney wrote:
>
> > > > > - both RCU stall detector and 'echo l > sysrq-trigger' can (and we've
> > > > > seen it happening for real) cause a complete, undebuggable, silent
> > > > > hang
> > > > >
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
> > > > - both RCU stall detector and 'echo l > sysrq-trigger' can (and we've
> > > > seen it happening for real) cause a complete, undebuggable, silent
> > > > hang
> > > > of machine (deadlock in NMI context)
> > >
> > > I could easily add an
On Wed, Jun 18, 2014 at 04:41:09PM +0200, Jiri Kosina wrote:
> On Wed, 18 Jun 2014, Paul E. McKenney wrote:
>
> > > - both RCU stall detector and 'echo l > sysrq-trigger' can (and we've
> > > seen it happening for real) cause a complete, undebuggable, silent hang
> > > of machine (deadlock
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
> > - both RCU stall detector and 'echo l > sysrq-trigger' can (and we've
> > seen it happening for real) cause a complete, undebuggable, silent hang
> > of machine (deadlock in NMI context)
>
> I could easily add an option to RCU to allow
On Wed, Jun 18, 2014 at 01:03:05PM +0200, Jiri Kosina wrote:
> On Tue, 10 Jun 2014, Linus Torvalds wrote:
>
> > > Lets be crazy and Cc Linus on that.
> >
> > Quite frankly, I hate seeing something like this:
> >
> > kernel/printk/printk.c | 1218
> >
On Tue, 10 Jun 2014, Linus Torvalds wrote:
> > Lets be crazy and Cc Linus on that.
>
> Quite frankly, I hate seeing something like this:
>
> kernel/printk/printk.c | 1218
> +--
>
> for something that is stupid and broken. Printing from NMI context
On Tue, 10 Jun 2014, Linus Torvalds wrote:
Lets be crazy and Cc Linus on that.
Quite frankly, I hate seeing something like this:
kernel/printk/printk.c | 1218
+--
for something that is stupid and broken. Printing from NMI context
isn't
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
- both RCU stall detector and 'echo l sysrq-trigger' can (and we've
seen it happening for real) cause a complete, undebuggable, silent hang
of machine (deadlock in NMI context)
I could easily add an option to RCU to allow people to tell
On Wed, Jun 18, 2014 at 04:41:09PM +0200, Jiri Kosina wrote:
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
- both RCU stall detector and 'echo l sysrq-trigger' can (and we've
seen it happening for real) cause a complete, undebuggable, silent hang
of machine (deadlock in NMI
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
- both RCU stall detector and 'echo l sysrq-trigger' can (and we've
seen it happening for real) cause a complete, undebuggable, silent
hang
of machine (deadlock in NMI context)
I could easily add an option to RCU to allow
On Wed, Jun 18, 2014 at 01:03:05PM +0200, Jiri Kosina wrote:
On Tue, 10 Jun 2014, Linus Torvalds wrote:
Lets be crazy and Cc Linus on that.
Quite frankly, I hate seeing something like this:
kernel/printk/printk.c | 1218
+--
for
On Wed, Jun 18, 2014 at 04:53:14PM +0200, Jiri Kosina wrote:
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
- both RCU stall detector and 'echo l sysrq-trigger' can (and we've
seen it happening for real) cause a complete, undebuggable, silent
hang
of machine (deadlock
On Wed, Jun 18, 2014 at 05:58:40AM -1000, Linus Torvalds wrote:
On Jun 18, 2014 4:36 AM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
I could easily add an option to RCU to allow people to tell it not to
use NMIs to dump the stack.
I don't think it should be an option.
We
On Wed, 18 Jun 2014 09:21:17 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Wed, Jun 18, 2014 at 05:58:40AM -1000, Linus Torvalds wrote:
On Jun 18, 2014 4:36 AM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
I could easily add an option to RCU to allow people to tell
On Wed, Jun 18, 2014 at 12:38:37PM -0400, Steven Rostedt wrote:
On Wed, 18 Jun 2014 09:21:17 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Wed, Jun 18, 2014 at 05:58:40AM -1000, Linus Torvalds wrote:
On Jun 18, 2014 4:36 AM, Paul E. McKenney paul...@linux.vnet.ibm.com
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
OK, unconditional non-use of NMIs is even easier. ;-)
Something like the following.
Thanx, Paul
rcu: Don't use
On Wed, Jun 18, 2014 at 10:36:10PM +0200, Jiri Kosina wrote:
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
OK, unconditional non-use of NMIs is even easier. ;-)
Something like the following.
Thanx, Paul
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
/* Complain about tasks blocking the grace period. */
@@ -1044,8 +1041,7 @@ static void print_cpu_stall(struct rcu_state *rsp)
pr_cont( (t=%lu jiffies g=%ld c=%ld q=%lu)\n,
jiffies - rsp-gp_start,
(long)rsp-gpnum,
On Wed, Jun 18, 2014 at 11:12:48PM +0200, Jiri Kosina wrote:
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
/* Complain about tasks blocking the grace period. */
@@ -1044,8 +1041,7 @@ static void print_cpu_stall(struct rcu_state *rsp)
pr_cont( (t=%lu jiffies g=%ld
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
I agree that it might work nicely for RCU stall detector indeed. I was
looking for solution that'd work nicely both for RCU and for sysrq-l
(where we can't rely on processess being stuck in any way).
Agreed. And if some more generally
On Wed, Jun 18, 2014 at 11:32:53PM +0200, Jiri Kosina wrote:
On Wed, 18 Jun 2014, Paul E. McKenney wrote:
I agree that it might work nicely for RCU stall detector indeed. I was
looking for solution that'd work nicely both for RCU and for sysrq-l
(where we can't rely on processess
On Wed, 18 Jun 2014 23:12:48 +0200 (CEST)
Jiri Kosina jkos...@suse.cz wrote:
I believe that this was what Steven was suggesting, though by using
tracing.
My understanding was that Steven is suggesting using trace_printk() from
NMI.
Not quite. I was suggesting using the ftrace ring
On Thu 29-05-14 02:09:11, Frederic Weisbecker wrote:
> On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
> > On Fri, 9 May 2014, Petr Mladek wrote:
> >
> > > printk() cannot be used safely in NMI context because it uses internal
> > > locks
> > > and thus could cause a deadlock.
On Thu 29-05-14 02:09:11, Frederic Weisbecker wrote:
On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
On Fri, 9 May 2014, Petr Mladek wrote:
printk() cannot be used safely in NMI context because it uses internal
locks
and thus could cause a deadlock. Unfortunately there
On Tue 2014-06-10 19:32:51, Jiri Kosina wrote:
> On Tue, 10 Jun 2014, Linus Torvalds wrote:
>
> > > Lets be crazy and Cc Linus on that.
> >
> > Quite frankly, I hate seeing something like this:
> >
> > kernel/printk/printk.c | 1218
> > +--
> >
> >
On Tue 2014-06-10 19:32:51, Jiri Kosina wrote:
On Tue, 10 Jun 2014, Linus Torvalds wrote:
Lets be crazy and Cc Linus on that.
Quite frankly, I hate seeing something like this:
kernel/printk/printk.c | 1218
+--
for something that
On Tue, 10 Jun 2014, Linus Torvalds wrote:
> > Lets be crazy and Cc Linus on that.
>
> Quite frankly, I hate seeing something like this:
>
> kernel/printk/printk.c | 1218
> +--
>
> for something that is stupid and broken. Printing from NMI context
On Tue, Jun 10, 2014 at 9:46 AM, Frederic Weisbecker wrote:
>
> There is also a big risk that if we push back this bugfix, nobody will
> actually do
> that desired rewrite.
>
> Lets be crazy and Cc Linus on that.
Quite frankly, I hate seeing something like this:
kernel/printk/printk.c
On Fri, May 30, 2014 at 10:13:28AM +0200, Jan Kara wrote:
> On Thu 29-05-14 02:09:11, Frederic Weisbecker wrote:
> > On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
> > > On Fri, 9 May 2014, Petr Mladek wrote:
> > >
> > > > printk() cannot be used safely in NMI context because it
On Thu, May 29, 2014 at 10:09:48AM +0200, Jiri Kosina wrote:
> On Thu, 29 May 2014, Frederic Weisbecker wrote:
>
> > > I am rather surprised that this patchset hasn't received a single review
> > > comment for 3 weeks.
> > >
> > > Let me point out that the issues Petr is talking about in the
On Thu, May 29, 2014 at 10:09:48AM +0200, Jiri Kosina wrote:
On Thu, 29 May 2014, Frederic Weisbecker wrote:
I am rather surprised that this patchset hasn't received a single review
comment for 3 weeks.
Let me point out that the issues Petr is talking about in the cover
letter
On Fri, May 30, 2014 at 10:13:28AM +0200, Jan Kara wrote:
On Thu 29-05-14 02:09:11, Frederic Weisbecker wrote:
On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
On Fri, 9 May 2014, Petr Mladek wrote:
printk() cannot be used safely in NMI context because it uses internal
On Tue, Jun 10, 2014 at 9:46 AM, Frederic Weisbecker fweis...@gmail.com wrote:
There is also a big risk that if we push back this bugfix, nobody will
actually do
that desired rewrite.
Lets be crazy and Cc Linus on that.
Quite frankly, I hate seeing something like this:
On Tue, 10 Jun 2014, Linus Torvalds wrote:
Lets be crazy and Cc Linus on that.
Quite frankly, I hate seeing something like this:
kernel/printk/printk.c | 1218
+--
for something that is stupid and broken. Printing from NMI context
isn't
On Fri, 30 May 2014, Jan Kara wrote:
> > Documentation/kernel-parameters.txt | 19 +-
> > kernel/printk/printk.c | 1218
> > +--
> > 2 files changed, 878 insertions(+), 359 deletions(-)
> >
> >
> > Your patches look clean and pretty nice
On Thu 29-05-14 02:09:11, Frederic Weisbecker wrote:
> On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
> > On Fri, 9 May 2014, Petr Mladek wrote:
> >
> > > printk() cannot be used safely in NMI context because it uses internal
> > > locks
> > > and thus could cause a deadlock.
On Thu 29-05-14 02:09:11, Frederic Weisbecker wrote:
On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
On Fri, 9 May 2014, Petr Mladek wrote:
printk() cannot be used safely in NMI context because it uses internal
locks
and thus could cause a deadlock. Unfortunately there
On Fri, 30 May 2014, Jan Kara wrote:
Documentation/kernel-parameters.txt | 19 +-
kernel/printk/printk.c | 1218
+--
2 files changed, 878 insertions(+), 359 deletions(-)
Your patches look clean and pretty nice actually. They must be
On Thu, 29 May 2014, Frederic Weisbecker wrote:
> > I am rather surprised that this patchset hasn't received a single review
> > comment for 3 weeks.
> >
> > Let me point out that the issues Petr is talking about in the cover letter
> > are real -- we've actually seen the lockups triggered by
On Thu, 29 May 2014, Frederic Weisbecker wrote:
I am rather surprised that this patchset hasn't received a single review
comment for 3 weeks.
Let me point out that the issues Petr is talking about in the cover letter
are real -- we've actually seen the lockups triggered by RCU stall
On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
> On Fri, 9 May 2014, Petr Mladek wrote:
>
> > printk() cannot be used safely in NMI context because it uses internal locks
> > and thus could cause a deadlock. Unfortunately there are circumstances when
> > calling printk from NMI is
On Fri, 9 May 2014, Petr Mladek wrote:
> printk() cannot be used safely in NMI context because it uses internal locks
> and thus could cause a deadlock. Unfortunately there are circumstances when
> calling printk from NMI is very useful. For example, all WARN.*(in_nmi())
> would be much more
On Fri, 9 May 2014, Petr Mladek wrote:
printk() cannot be used safely in NMI context because it uses internal locks
and thus could cause a deadlock. Unfortunately there are circumstances when
calling printk from NMI is very useful. For example, all WARN.*(in_nmi())
would be much more helpful
On Thu, May 29, 2014 at 12:02:30AM +0200, Jiri Kosina wrote:
On Fri, 9 May 2014, Petr Mladek wrote:
printk() cannot be used safely in NMI context because it uses internal locks
and thus could cause a deadlock. Unfortunately there are circumstances when
calling printk from NMI is very
printk() cannot be used safely in NMI context because it uses internal locks
and thus could cause a deadlock. Unfortunately there are circumstances when
calling printk from NMI is very useful. For example, all WARN.*(in_nmi())
would be much more helpful if they didn't lockup the machine.
Another
printk() cannot be used safely in NMI context because it uses internal locks
and thus could cause a deadlock. Unfortunately there are circumstances when
calling printk from NMI is very useful. For example, all WARN.*(in_nmi())
would be much more helpful if they didn't lockup the machine.
Another
56 matches
Mail list logo
