Hello,
On (09/02/16 17:15), Petr Mladek wrote:
[..]
> > I meant that this thing
> >
> > local_irq_save() // or preempt_disable()
> > ...
> > if (console_trylock())
> > console_unlock();
> > ...
> > local_irq_restore() // or preempt_enable()
>
> I see.
>
> > can e
On Fri 2016-09-02 16:58:08, Sergey Senozhatsky wrote:
> On (09/01/16 10:58), Petr Mladek wrote:
> > On Wed 2016-08-31 21:52:24, Sergey Senozhatsky wrote:
> > > a console_unlock() doing
> > > wake_up_process(printk_kthread) would make it better.
> >
> > I am not sure what you mean by this.
>
> I m
On (09/01/16 10:58), Petr Mladek wrote:
> On Wed 2016-08-31 21:52:24, Sergey Senozhatsky wrote:
> > On (08/31/16 11:38), Petr Mladek wrote:
> > > 2. Potential deadlocks when calling wake_up_process() by
> > > async printk and console_unlock().
> >
> > * there are many reasons to those r
On Wed 2016-08-31 21:52:24, Sergey Senozhatsky wrote:
> On (08/31/16 11:38), Petr Mladek wrote:
> > 2. Potential deadlocks when calling wake_up_process() by
> > async printk and console_unlock().
>
> * there are many reasons to those recursive printk() calls -- some
> can be addressed,
On (08/31/16 11:38), Petr Mladek wrote:
[..]
> Ah, I do not want to discourage you from finding a solution for these
> problems.
oh, Petr, I didn't mean it. that was a poor/incorrect wording on my side.
> I just wanted to point out problems with this particular
> path of thinking (more per-CPU bu
On Wed 2016-08-31 11:31:35, Sergey Senozhatsky wrote:
> On (08/30/16 11:29), Petr Mladek wrote:
> > > you didn't miss anything, I think I wasn't too descriptive and that caused
> > > some confusion. this patch is not a replacement of wake_up_process() patch
> > > posted earlier in the loop, but an
On (08/30/16 11:29), Petr Mladek wrote:
> > you didn't miss anything, I think I wasn't too descriptive and that caused
> > some confusion. this patch is not a replacement of wake_up_process() patch
> > posted earlier in the loop, but an addition to it. not only every WARN/BUG
> > issued from wake_u
On Fri 2016-08-26 10:56:41, Sergey Senozhatsky wrote:
> On (08/25/16 23:10), Petr Mladek wrote:
> [..]
> > I was so taken by the idea of temporary forcing a lockless and
> > "trivial" printk implementation that I missed one thing.
> >
> > Your patch use the alternative printk() variant around logb
On (08/26/16 10:56), Sergey Senozhatsky wrote:
> but every lock we take is potentially dangerous as well.
...
> vprintk_emit()
> {
> alt_printk_enter();
> ...
> log_store();
> ...
> alt_printk_exit();
>
> wakep_up_process() /* direct from async printk,
>
On (08/25/16 23:10), Petr Mladek wrote:
[..]
> I was so taken by the idea of temporary forcing a lockless and
> "trivial" printk implementation that I missed one thing.
>
> Your patch use the alternative printk() variant around logbuf_lock.
> But this is not the problem with wake_up_process(). pri
On Mon 2016-08-22 13:15:20, Sergey Senozhatsky wrote:
> Hello,
>
> On (08/20/16 14:24), Sergey Senozhatsky wrote:
> > On (08/19/16 21:00), Jan Kara wrote:
> > > > > depending on .config BUG() may never return back -- passing control
> > > > > to do_exit(), so printk_deferred_exit() won't be execut
On (08/23/16 14:19), Petr Mladek wrote:
> > the other thing I just thought of is doing something as follows
> > !!!not tested, will not compile, just an idea!!!
> >
> > ---
> >
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 6e260a0..bb8d719 100644
> > --- a/kernel/prin
On Fri 2016-08-19 21:00:07, Jan Kara wrote:
> On Fri 19-08-16 11:54:55, Petr Mladek wrote:
> > On Fri 2016-08-19 15:32:36, Sergey Senozhatsky wrote:
> > > On (08/18/16 12:56), Petr Mladek wrote:
> > > > The advantage of the printk_func trick is that it is transparent.
> > > > You do not need to mod
On Sat 2016-08-20 14:24:30, Sergey Senozhatsky wrote:
> On (08/19/16 21:00), Jan Kara wrote:
> > > > depending on .config BUG() may never return back -- passing control
> > > > to do_exit(), so printk_deferred_exit() won't be executed. thus we
> > > > probably need to have a per-cpu variable that w
On Mon 2016-08-22 13:15:20, Sergey Senozhatsky wrote:
> Hello,
>
> On (08/20/16 14:24), Sergey Senozhatsky wrote:
> > On (08/19/16 21:00), Jan Kara wrote:
> > > > > depending on .config BUG() may never return back -- passing control
> > > > > to do_exit(), so printk_deferred_exit() won't be execut
[I *AGAIN* seem to have lost access to linux-kernel subscription,
thus no proper In-Reply-To: reply possible, ARGH, sorry]
Some random yet maybe still helpful observations from
reading this mail content
(Sat, 20 Aug 2016 14:24:30 +0900)
and reviewing trunk printk.c:
. vprintk_emit() static variab
Hello,
On (08/20/16 14:24), Sergey Senozhatsky wrote:
> On (08/19/16 21:00), Jan Kara wrote:
> > > > depending on .config BUG() may never return back -- passing control
> > > > to do_exit(), so printk_deferred_exit() won't be executed. thus we
> > > > probably need to have a per-cpu variable that
On (08/19/16 21:00), Jan Kara wrote:
> > > depending on .config BUG() may never return back -- passing control
> > > to do_exit(), so printk_deferred_exit() won't be executed. thus we
> > > probably need to have a per-cpu variable that would indicate that
> > > we are in deferred_bug. hm... but do
On Fri 19-08-16 11:54:55, Petr Mladek wrote:
> On Fri 2016-08-19 15:32:36, Sergey Senozhatsky wrote:
> > On (08/18/16 12:56), Petr Mladek wrote:
> > > The advantage of the printk_func trick is that it is transparent.
> > > You do not need to modify any existing functions used by WARN()/BUG()
> > >
On Fri 2016-08-19 15:32:36, Sergey Senozhatsky wrote:
> On (08/18/16 12:56), Petr Mladek wrote:
> > The advantage of the printk_func trick is that it is transparent.
> > You do not need to modify any existing functions used by WARN()/BUG()
> > macros.
>
> good point.
>
> so something like below,
On (08/18/16 12:56), Petr Mladek wrote:
> On Thu 2016-08-18 18:51:44, Sergey Senozhatsky wrote:
> > On (08/18/16 11:33), Petr Mladek wrote:
> > [..]
> > > > > 2. Force synchronous printk inside WARN()/BUG() macros.
> > > >
> > > > will it help? semaphore up() calls wake_up_process() regardless the
On Thu 2016-08-18 18:51:44, Sergey Senozhatsky wrote:
> On (08/18/16 11:33), Petr Mladek wrote:
> [..]
> > > > 2. Force synchronous printk inside WARN()/BUG() macros.
> > >
> > > will it help? semaphore up() calls wake_up_process() regardless the
> > > context.
> > > not to mention that we still
On (08/18/16 11:33), Petr Mladek wrote:
[..]
> > > 2. Force synchronous printk inside WARN()/BUG() macros.
> >
> > will it help? semaphore up() calls wake_up_process() regardless the context.
> > not to mention that we still may have spin_dump() enabled.
>
> Good point. That changes my preference
On Thu 2016-08-18 11:27:12, Sergey Senozhatsky wrote:
> Hello,
>
> really sorry for very long reply.
>
> On (08/12/16 11:44), Petr Mladek wrote:
> [..]
> > IMHO, this is fine. We force the synchronous mode in critical
> > situations anyway.
>
> yes, I think it makes sense to lower the priority (
Hello,
really sorry for very long reply.
On (08/12/16 11:44), Petr Mladek wrote:
[..]
> IMHO, this is fine. We force the synchronous mode in critical
> situations anyway.
yes, I think it makes sense to lower the priority (we also have
briefly discussed this in private emails with Viresh). I'd st
On Mon 2016-08-15 17:26:50, Vladislav Levenetz wrote:
> On 08/12/2016 12:44 PM, Petr Mladek wrote:
> >But I was curious if we could hit a printk from the wake_up_process().
> >The change above causes using the fair scheduler and there is
> >the following call chain [*]
> >
> > vprintk_emit()
> >
On 08/12/2016 12:44 PM, Petr Mladek wrote:
On Wed 2016-08-10 14:17:55, Viresh Kumar wrote:
+Vladi/Greg,
On Wed, Apr 6, 2016 at 1:27 AM, Jan Kara wrote:
On Mon 04-04-16 15:51:49, Andrew Morton wrote:
+static int __init init_printk_kthread(void)
+{
+ struct task_struct *thread;
+
+ if (p
On Wed 2016-08-10 14:17:55, Viresh Kumar wrote:
> +Vladi/Greg,
>
> On Wed, Apr 6, 2016 at 1:27 AM, Jan Kara wrote:
> > On Mon 04-04-16 15:51:49, Andrew Morton wrote:
>
> >> > +static int __init init_printk_kthread(void)
> >> > +{
> >> > + struct task_struct *thread;
> >> > +
> >> > + if (pri
+Vladi/Greg,
On Wed, Apr 6, 2016 at 1:27 AM, Jan Kara wrote:
> On Mon 04-04-16 15:51:49, Andrew Morton wrote:
>> > +static int __init init_printk_kthread(void)
>> > +{
>> > + struct task_struct *thread;
>> > +
>> > + if (printk_sync)
>> > + return 0;
>> > +
>> > + thread = kthrea
On Thu 07-04-16 21:08:26, Sergey Senozhatsky wrote:
> Hello,
>
> On (04/07/16 18:48), Sergey Senozhatsky wrote:
> > On (04/06/16 10:27), Jan Kara wrote:
> > [..]
> > > > Well, it's good that we have this.
> > > >
> > > > It would be better if it was runtime-controllable - changing boot
> > > > pa
Hello,
On (04/07/16 18:48), Sergey Senozhatsky wrote:
> On (04/06/16 10:27), Jan Kara wrote:
> [..]
> > > Well, it's good that we have this.
> > >
> > > It would be better if it was runtime-controllable - changing boot
> > > parameters is a bit of a pain. In fact with this approach, your
> > > z
Hello,
On (04/06/16 10:27), Jan Kara wrote:
[..]
> > Well, it's good that we have this.
> >
> > It would be better if it was runtime-controllable - changing boot
> > parameters is a bit of a pain. In fact with this approach, your
> > zillions-of-scsi-disks scenario becomes less problematic: do t
On Mon 04-04-16 15:51:49, Andrew Morton wrote:
> On Tue, 5 Apr 2016 01:57:27 +0900 Sergey Senozhatsky
> wrote:
>
> > From: Jan Kara
> >
> > Currently, printk() sometimes waits for message to be printed to console
> > and sometimes it does not (when console_sem is held by some other
> > proces
Hello,
so I currently have something like this.
untouched things:
- module param is RO; offload printing to kthread
(I'll wait for opinions/replies).
===
>From 1e7de1f9a590d8f23609f943362768e4c14580cc Mon Sep 17 00:00:00 2001
From: Jan Kara
Date: Tue, 5 Apr 2016 01:57:27 +0900
Subject:
On (04/05/16 14:17), Sergey Senozhatsky wrote:
[..]
> > Could do with a comment explaining why late_initcall was chosen.
>
> late_initcall was chosen because of workqueue early_initcall, and
> I just decided not to change it when I switched from wq to a
> dedicated printk kthread. late_initcall se
Hello Andrew,
On (04/04/16 15:51), Andrew Morton wrote:
[..]
> The whole idea remains worrisome. It is definitely making printk()
> less reliable in the vast majority of cases: what happens if the
> scheduler is busted or random memory has been scribbled on, etc.
yes.
well, printk, in some sens
On Tue, 5 Apr 2016 01:57:27 +0900 Sergey Senozhatsky
wrote:
> From: Jan Kara
>
> Currently, printk() sometimes waits for message to be printed to console
> and sometimes it does not (when console_sem is held by some other
> process). In case printk() grabs console_sem and starts printing to
>
From: Jan Kara
Currently, printk() sometimes waits for message to be printed to console
and sometimes it does not (when console_sem is held by some other
process). In case printk() grabs console_sem and starts printing to
console, it prints messages from kernel printk buffer until the buffer
is e
38 matches
Mail list logo
