On (02/02/17 16:20), Petr Mladek wrote:
> > well, I wouldn't say that printk_deferred() has less chances. I see your
> > point, of course. but with printk_deferred() we, at least, will have
> > messages
> > in logbuf (or printk_safe buffers), so they can appear in crash dump, for
> > instance. tha
On Thu 2017-02-02 19:03:48, Sergey Senozhatsky wrote:
> On (02/02/17 10:07), Peter Zijlstra wrote:
> > On Thu, Feb 02, 2017 at 11:11:34AM +0900, Sergey Senozhatsky wrote:
> > > On (02/01/17 16:39), Petr Mladek wrote:
> > > [..]
> > > > I guess that you are talking about the introduction of
> > > >
On (02/02/17 10:07), Peter Zijlstra wrote:
> On Thu, Feb 02, 2017 at 11:11:34AM +0900, Sergey Senozhatsky wrote:
> > On (02/01/17 16:39), Petr Mladek wrote:
> > [..]
> > > I guess that you are talking about the introduction of
> > > #define SCHED_WARN_ON(x) WARN_ONCE(x, #x)
> >
> > my guess would
On Thu, Feb 02, 2017 at 11:11:34AM +0900, Sergey Senozhatsky wrote:
> On (02/01/17 16:39), Petr Mladek wrote:
> [..]
> > I guess that you are talking about the introduction of
> > #define SCHED_WARN_ON(x)WARN_ONCE(x, #x)
>
> my guess would be that Jan was talking about printk_deferred() patch.
On (02/01/17 12:04), Steven Rostedt wrote:
> > [..]
> >
> > Signed-off-by: Sergey Senozhatsky
> > Reviewed-by: Petr Mladek
> > ---
>
> Reviewed-by: Steven Rostedt (VMware)
here and in other patches: thanks for taking a look, Steven.
-ss
On (02/01/17 16:39), Petr Mladek wrote:
[..]
> I guess that you are talking about the introduction of
> #define SCHED_WARN_ON(x) WARN_ONCE(x, #x)
my guess would be that Jan was talking about printk_deferred() patch.
it's on my TODO list.
I want to entirely remove console_sem and scheduler ou
Hello Ross,
I was offline for a week for personal reasons.
On (01/31/17 10:27), Ross Zwisler wrote:
[..]
> [ 13.090634] ==
> [ 13.090634] [ INFO: possible circular locking dependency detected ]
> [ 13.090635] 4.10.0-rc5-mm1-00313-g5c0c3d7-
On Tue, 27 Dec 2016 23:16:09 +0900
Sergey Senozhatsky wrote:
> Use printk_safe per-CPU buffers in printk recursion-prone blocks:
> -- around logbuf_lock protected sections in vprintk_emit() and
>console_unlock()
> -- around down_trylock_console_sem() and up_console_sem()
>
> Note that this s
On Wed, 1 Feb 2017 17:15:41 +0100
Peter Zijlstra wrote:
> So my kernel doesn't yet have that abomination; that redirects it to a
> buffer for later printing right? I hope that buffer is big enough to
> hold a full WARN splat and the machine lives long enough to make it to
> printing that crap.
On Wed, Feb 01, 2017 at 04:39:10PM +0100, Petr Mladek wrote:
> I guess that you are talking about the introduction of
> #define SCHED_WARN_ON(x) WARN_ONCE(x, #x)
No, there's a lot of regular WARN/WARN_ON/etc.. usage in the scheduler.
That thing was just a convenience wapper to print the condi
On Wed 2017-02-01 10:37:39, Peter Zijlstra wrote:
> On Wed, Feb 01, 2017 at 10:06:25AM +0100, Jan Kara wrote:
> > Clearly scheduler code (update_load_avg) calls WARN_ON from scheduler while
> > holding rq_lock which has been always forbidden. Sergey and Petr were doing
> > some work to prevent simi
On Wed, Feb 01, 2017 at 10:06:25AM +0100, Jan Kara wrote:
> Clearly scheduler code (update_load_avg) calls WARN_ON from scheduler while
> holding rq_lock which has been always forbidden. Sergey and Petr were doing
> some work to prevent similar deadlocks but I'm not sure how far they
> went...
Its
On Tue 31-01-17 10:27:53, Ross Zwisler wrote:
> On Tue, Dec 27, 2016 at 7:16 AM, Sergey Senozhatsky
> wrote:
> > Use printk_safe per-CPU buffers in printk recursion-prone blocks:
> > -- around logbuf_lock protected sections in vprintk_emit() and
> >console_unlock()
> > -- around down_trylock_c
On Tue, Dec 27, 2016 at 7:16 AM, Sergey Senozhatsky
wrote:
> Use printk_safe per-CPU buffers in printk recursion-prone blocks:
> -- around logbuf_lock protected sections in vprintk_emit() and
>console_unlock()
> -- around down_trylock_console_sem() and up_console_sem()
>
> Note that this solut
14 matches
Mail list logo
