On (02/26/19 19:24), Tetsuo Handa wrote:
> Does memory allocation by network stack / driver while trying to emit
> the messages include __GFP_DIRECT_RECLAIM flag (e.g. GFP_KERNEL) ?
> Commit 400e22499dd92613821 handles only memory allocations with
> __GFP_DIRECT_RECLAIM flag. If memory allocation w
On 2018/05/09 21:00, Petr Mladek wrote:
But we first need a real reason. Right now it looks to me like
we have "a solution" to a problem which we have never witnessed.
>>>
>>> I am trying to find a "simple" and generic solution for the problem
>>> reported by Tejun:
>> [..]
>>> 1. Console
On Wed, 9 May 2018 14:00:50 +0200
Petr Mladek wrote:
> IMHO, if con->write() wants to add more than 1000 (or 100 or whatever
> sane limit) new lines then something is really wrong and we should
> stop it. It is that simple.
>
+1
-- Steve
On Fri 2018-04-27 19:22:45, Sergey Senozhatsky wrote:
> On (04/26/18 11:42), Petr Mladek wrote:
> [..]
> > Honestly, I do not believe that console drivers are like Scheherazade.
> > They are not able to make up long interesting stories. Let's say that
> > lockdep splat has more than 100 lines but i
On (04/26/18 11:42), Petr Mladek wrote:
[..]
>
> Believe me, I could perfectly understand the desire to create perfect
> defensive solutions that would never break anything. It is not easy
> to decide when the best-effort solutions are worth the risk.
Yes, but my point is - I don't think we clear
On Wed 2018-04-25 14:31:46, Sergey Senozhatsky wrote:
> On (04/23/18 14:45), Petr Mladek wrote:
> [..]
> > I am not sure how slow are the slowest consoles. If I take that
> > everything should be faster than 1200 bauds. Then 10 minutes
> > should be enough for 1000 lines and 80 characters per-line:
On (04/23/18 14:45), Petr Mladek wrote:
[..]
> I am not sure how slow are the slowest consoles. If I take that
> everything should be faster than 1200 bauds. Then 10 minutes
> should be enough for 1000 lines and 80 characters per-line:
Well, the problem with the numbers is that they are too... sim
On (04/23/18 14:26), Petr Mladek wrote:
> need to see the problems and be able to debug them. BTW: I wrote
> this in the patch description.
>
> > A very quick googling:
>
> Nice collection. Just note that the useful (ratelimited) information
> always fits into the first 100 lines in all these exa
On Mon 2018-04-23 07:36:03, Steven Rostedt wrote:
> On Mon, 23 Apr 2018 12:32:32 +0200
> Ug, you're right. Somehow when I looked at where console_owner was set
> "console_lock_spinning_enabled" I saw it as "console_trylock_spinning".
>
> This is what I get when I'm trying to follow three threads a
On Mon 2018-04-23 14:21:33, Sergey Senozhatsky wrote:
> On (04/20/18 11:12), Petr Mladek wrote:
> call_console_drivers() is super complex, unbelievable complex. In fact,
> it's so complex that we never know where we will end up, because it can
> pass the control to almost every core kernel mechanis
On Mon, 23 Apr 2018 12:32:32 +0200
Petr Mladek wrote:
> > Really?
> >
> >
> > console_trylock_spinning(); /* console_owner now equals current */
>
> No, console_trylock_spinning() does not modify console_owner. The
> handshake is done using console_waiter variable.
Ug, you're right. Someh
On Fri 2018-04-20 11:13:07, Steven Rostedt wrote:
> On Fri, 20 Apr 2018 16:57:20 +0200
> Petr Mladek wrote:
>
>
> > No, call_console_drivers() is done with interrupts disabled:
> >
> > console_lock_spinning_enable();
> >
> > stop_critical_timings();/* don't trac
On (04/20/18 11:12), Petr Mladek wrote:
[..]
> Will 1000 lines within 1 hour be enough for you, please?
I'm afraid it won't.
> I am lost. In the mail
[..]
> My understanding of the older mail is that you called
> console_drivers() in printk_safe() context only because it was
> easier to disable p
On Fri, 20 Apr 2018 16:57:20 +0200
Petr Mladek wrote:
> No, call_console_drivers() is done with interrupts disabled:
>
> console_lock_spinning_enable();
>
> stop_critical_timings();/* don't trace print latency */
> >call_console_drivers(
On Fri 2018-04-20 10:17:51, Steven Rostedt wrote:
> On Fri, 20 Apr 2018 16:01:57 +0200
> Petr Mladek wrote:
> > On Fri 2018-04-20 08:04:28, Steven Rostedt wrote:
> > > The problem is the way rate limit works. If you print 100 lines (or
> > > 1000) in 5 seconds, then you just stopped printing from
On Fri, 20 Apr 2018 10:17:51 -0400
Steven Rostedt wrote:
> int git_context(void)
That should have been get_context(void) ;-)
-- Steve
On Fri, 20 Apr 2018 16:01:57 +0200
Petr Mladek wrote:
> On Fri 2018-04-20 08:04:28, Steven Rostedt wrote:
> > On Fri, 20 Apr 2018 11:12:24 +0200
> > Petr Mladek wrote:
> >
> > > Yes, my number was arbitrary. The important thing is that it was long
> > > enough. Or do you know about an console
On Fri 2018-04-20 08:04:28, Steven Rostedt wrote:
> On Fri, 20 Apr 2018 11:12:24 +0200
> Petr Mladek wrote:
>
> > Yes, my number was arbitrary. The important thing is that it was long
> > enough. Or do you know about an console that will not be able to write
> > 100 lines within one hour?
>
> Th
On Fri, 20 Apr 2018 11:12:24 +0200
Petr Mladek wrote:
> Yes, my number was arbitrary. The important thing is that it was long
> enough. Or do you know about an console that will not be able to write
> 100 lines within one hour?
The problem is the way rate limit works. If you print 100 lines (or
On Fri 2018-04-20 11:15:11, Sergey Senozhatsky wrote:
> On (04/19/18 14:53), Petr Mladek wrote:
> > > > >
> > > > > Besides 100 lines is absolutely not enough for any real lockdep splat.
> > > > > My call would be - up to 1000 lines in a 1 minute interval.
> >
> > But this would break the intenti
On (04/19/18 14:53), Petr Mladek wrote:
> > > >
> > > > Besides 100 lines is absolutely not enough for any real lockdep splat.
> > > > My call would be - up to 1000 lines in a 1 minute interval.
>
> But this would break the intention of this patch.
You picked an arbitrary value and now you are s
On Mon 2018-04-16 13:25:53, Sergey Senozhatsky wrote:
> On (04/16/18 10:47), Sergey Senozhatsky wrote:
> > On (04/14/18 11:35), Sergey Senozhatsky wrote:
> > > On (04/13/18 10:12), Steven Rostedt wrote:
> > > >
> > > > > The interval is set to one hour. It is rather arbitrary selected time.
> > >
On (04/16/18 10:47), Sergey Senozhatsky wrote:
> On (04/14/18 11:35), Sergey Senozhatsky wrote:
> > On (04/13/18 10:12), Steven Rostedt wrote:
> > >
> > > > The interval is set to one hour. It is rather arbitrary selected time.
> > > > It is supposed to be a compromise between never print these me
On (04/14/18 11:35), Sergey Senozhatsky wrote:
> On (04/13/18 10:12), Steven Rostedt wrote:
> >
> > > The interval is set to one hour. It is rather arbitrary selected time.
> > > It is supposed to be a compromise between never print these messages,
> > > do not lockup the machine, do not fill the
On (04/13/18 10:12), Steven Rostedt wrote:
>
> > The interval is set to one hour. It is rather arbitrary selected time.
> > It is supposed to be a compromise between never print these messages,
> > do not lockup the machine, do not fill the entire buffer too quickly,
> > and get information if som
On Fri, 13 Apr 2018 14:47:04 +0200
Petr Mladek wrote:
> The interval is set to one hour. It is rather arbitrary selected time.
> It is supposed to be a compromise between never print these messages,
> do not lockup the machine, do not fill the entire buffer too quickly,
> and get information if
Error messages printed by console drivers might cause an infinite loop.
In particular, writing a message might produce another message that
need to be written, etc.
The obvious solution is to remove these messages. But there many
non-trivial console drivers. Also showing printk() messages is not
t
27 matches
Mail list logo
