On Mon 2016-10-24 19:22:59, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 7:06 PM, Linus Torvalds
> wrote:
> > On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky
> > wrote:
> >>
> >> I think cont_flush() should grab the logbuf_lock lock, because
> >> it does log_store() and touches the cont.le
On Mon 2016-10-24 19:22:59, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 7:06 PM, Linus Torvalds
> wrote:
> > On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky
> > wrote:
> >>
> >> I think cont_flush() should grab the logbuf_lock lock, because
> >> it does log_store() and touches the cont.le
On Sun, Oct 23, 2016 at 11:11:18AM -0700, Linus Torvalds wrote:
>
> For example, one of the really historical uses for partial lines is this:
>
>pr_info("Checking 'hlt' instruction... ");
>
>if (!boot_cpu_data.hlt_works_ok) {
>pr_cont("disabled\n");
>
On (10/24/16 21:15), Linus Torvalds wrote:
[..]
> No. Most cont lines never hit the delay, because when the line is
> completed, it is flushed (and then printed synchronously, assuming it
> can get the console lock).
>
> So the timeout only ever comes into effect if the line isn't completed
> in t
On Mon, Oct 24, 2016 at 9:06 PM, Sergey Senozhatsky
wrote:
>
> 1) the way we dumpstack on x86 (at least on x86) is a spaghetti of
> printk() and pr_cont() calls. for instance, arch/x86/kernel/dumpstack_64.c
> show_regs() does pr_cont() to print out the registers, while the stack and
> backtrace ar
On Tue, 2016-10-25 at 13:06 +0900, Sergey Senozhatsky wrote:
> so how about skipping mod_timer in deferred_cont_flush() and just
> cont_flush() when we are in oops? here is probably one more thing we
> need to "fix" first. oops_in_progress is unreliable. x86 oops_end()
> does bust_spinlocks
On (10/24/16 19:22), Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 7:06 PM, Linus Torvalds
> wrote:
> > On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky
> > wrote:
> >>
> >> I think cont_flush() should grab the logbuf_lock lock, because
> >> it does log_store() and touches the cont.len. so s
On (10/25/16 10:55), Sergey Senozhatsky wrote:
> I think cont_flush() should grab the logbuf_lock lock, because
> it does log_store() and touches the cont.len. so something like
> this perhaps
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index c7f490f..47f887c 100644
> --- a/
On Mon, Oct 24, 2016 at 7:06 PM, Linus Torvalds
wrote:
> On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky
> wrote:
>>
>> I think cont_flush() should grab the logbuf_lock lock, because
>> it does log_store() and touches the cont.len. so something like
>> this perhaps
>
> Absolutely. Good catch.
On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky
wrote:
>
> I think cont_flush() should grab the logbuf_lock lock, because
> it does log_store() and touches the cont.len. so something like
> this perhaps
Absolutely. Good catch.
>> - if (wake_klogd)
>> + if (wake_klogd || cont.len)
>
Hello,
Cc more people
report: https://marc.info/?l=linux-kernel&m=147721454506634&w=2
patch: https://marc.info/?l=linux-kernel&m=147733173800859
FB is using ext header a lot (afaik), so may be Tejun or Calvin
will also be interested.
On (10/24/16 10:55), Linus Torvalds wrote:
> > Note the "to
On Mon, Oct 24, 2016 at 10:54 AM, Linus Torvalds
wrote:
>
> Note the "totally untested" part. It compiles for me. But it may do
> unspeakably stupid things. Caveat applior.
Well, it is hard to apply a patch that I didn't even attach. Blush.
Linus
kernel/printk/printk.c | 249
On Mon, Oct 24, 2016 at 7:08 AM, Sergey Senozhatsky
wrote:
>
> is mod_timer() safe enough to rely on/call from
> panic()->console_flush_on_panic()->console_unlock() ?
I don't think that's a big issue: the whole "panic()" siotuation is
very much about best effort.
> shouldn't deferred_con
> On (10/23/16 12:46), Linus Torvalds wrote:
> > +static void deferred_cont_flush(void)
> > +{
> > + static DEFINE_TIMER(timer, flush_timer, 0, 0);
> > +
> > + if (!cont.len)
> > return;
> > + mod_timer(&timer, jiffies + HZ/10);
> > }
>
> [..]
>
> > @@ -2360,6 +2285,8 @@ void c
Hello,
thanks for Cc-ing.
On (10/23/16 12:46), Linus Torvalds wrote:
> +static void deferred_cont_flush(void)
> +{
> + static DEFINE_TIMER(timer, flush_timer, 0, 0);
> +
> + if (!cont.len)
> return;
> + mod_timer(&timer, jiffies + HZ/10);
> }
[..]
> @@ -2360,6 +2285,8
Hi Linus,
On Sun, Oct 23, 2016 at 9:46 PM, Linus Torvalds
wrote:
> On Sun, Oct 23, 2016 at 12:32 PM, Linus Torvalds
> wrote:
>>
>> No, the real complexity comes from that interaction with the console
>> output, which is done outside the core log locks, and which currently
>> has the added thing
On Sun, Oct 23, 2016 at 1:33 PM, Joe Perches wrote:
>
> Perhaps it could be a pool of active thread
> continuation buffers.
Yes, we could probably do with just a couple of entries. Even just two
would probably catch almost all cases.
That said, having dealt with that code, I'd hate to make it mo
On Sun, 2016-10-23 at 12:32 -0700, Linus Torvalds wrote:
> On Sun, Oct 23, 2016 at 12:06 PM, Joe Perches wrote:
> > On Sun, 2016-10-23 at 11:11 -0700, Linus Torvalds wrote:
> > >
> > > And those two per se sound fairly easy to handle ("KERN_CONT means
> > > append to the line buffer, otherwise fl
On Sun, Oct 23, 2016 at 12:32 PM, Linus Torvalds
wrote:
>
> No, the real complexity comes from that interaction with the console
> output, which is done outside the core log locks, and which currently
> has the added thing where we have a "has this line fragment been
> flushed or not".
Ok, so her
On Sun, Oct 23, 2016 at 12:06 PM, Joe Perches wrote:
> On Sun, 2016-10-23 at 11:11 -0700, Linus Torvalds wrote:
>>
>> And those two per se sound fairly easy to handle ("KERN_CONT means
>> append to the line buffer, otherwise flush the line buffer and move to
>> the record buffer").
>>
>> But what
On Sun, 2016-10-23 at 11:11 -0700, Linus Torvalds wrote:
> On Sun, Oct 23, 2016 at 2:22 AM, Geert Uytterhoeven
> wrote:
> >
> > These changes have an interesting side-effect on sequences of printk()s that
> > lack proper continuation: they introduced a discrepancy between dmesg output
> > and the
On Sun, Oct 23, 2016 at 2:22 AM, Geert Uytterhoeven
wrote:
>
> These changes have an interesting side-effect on sequences of printk()s that
> lack proper continuation: they introduced a discrepancy between dmesg output
> and the actual kernel output.
Yes.
So the "print vs log" handling is really
Hi Linus,
On Wed, Oct 12, 2016 at 5:47 PM, Linus Torvalds
wrote:
> On Wed, Oct 12, 2016 at 6:30 AM, Tetsuo Handa
> wrote:
>>
>> I noticed that current linux.git generates hardly readable console output
>> due to KERN_CONT changes. Are you suggesting developers that output like
>> this be fixed?
On Thu 13-10-16 03:20:50, Joe Perches wrote:
> On Thu, 2016-10-13 at 12:04 +0200, Michal Hocko wrote:
[...]
> > I would be really surprised if we really had that many continuation
> > lines. They should be avoided as much as possible. Hundreds of thousands
> > just sounds more than over exaggerated
On Thu, 2016-10-13 at 12:04 +0200, Michal Hocko wrote:
> On Thu 13-10-16 02:29:46, Joe Perches wrote:
> > On Thu, 2016-10-13 at 08:26 +0200, Michal Hocko wrote:
>
> [...]
> > > I think they are not critical and can be fix once somebody notices.
> >
> >
> > As do I, but Linus objected to applyin
On Thu 13-10-16 02:29:46, Joe Perches wrote:
> On Thu, 2016-10-13 at 08:26 +0200, Michal Hocko wrote:
[...]
> > I think they are not critical and can be fix once somebody notices.
>
> As do I, but Linus objected to applying a patch when Colin Ian King
> noticed one.
>
> I think the 250,000 or so
On Thu, 2016-10-13 at 08:26 +0200, Michal Hocko wrote:
> On Wed 12-10-16 09:08:58, Joe Perches wrote:
> > On Wed, 2016-10-12 at 16:35 +0200, Michal Hocko wrote:
> > > On Wed 12-10-16 22:30:03, Tetsuo Handa wrote:
> > > > Hello.
> > > >
> > > > I noticed that current linux.git generates hardly read
On Wed 12-10-16 09:08:58, Joe Perches wrote:
> On Wed, 2016-10-12 at 16:35 +0200, Michal Hocko wrote:
> > On Wed 12-10-16 22:30:03, Tetsuo Handa wrote:
> > > Hello.
> > >
> > > I noticed that current linux.git generates hardly readable console output
> > > due to KERN_CONT changes. Are you suggest
On Wed, Oct 12, 2016 at 9:16 AM, Joe Perches wrote:
>> (but with the new world order you actually *can* combine KERN_CONT
>> with a loglevel, so that if the beginning od the line got flushed, the
>> continuation can still be printed with the right log level).
>
> I think that might not be a good i
On Wed, 2016-10-12 at 08:47 -0700, Linus Torvalds wrote:
< We'll see. But the other issues are easily fixed by just adding
> KERN_CONT where appropriate. It was actually very much what you were
> supposed to do before too, if only as a marker to others that "yes,
> I'm actually doing this, and no,
On Wed, 2016-10-12 at 16:35 +0200, Michal Hocko wrote:
> On Wed 12-10-16 22:30:03, Tetsuo Handa wrote:
> > Hello.
> >
> > I noticed that current linux.git generates hardly readable console output
> > due to KERN_CONT changes. Are you suggesting developers that output like
> > this be fixed?
>
>
On Wed, Oct 12, 2016 at 6:30 AM, Tetsuo Handa
wrote:
>
> I noticed that current linux.git generates hardly readable console output
> due to KERN_CONT changes. Are you suggesting developers that output like
> this be fixed?
Yes. Needing to add a few KERN_CONT markers was pretty much expected,
sinc
On Wed 12-10-16 22:30:03, Tetsuo Handa wrote:
> Hello.
>
> I noticed that current linux.git generates hardly readable console output
> due to KERN_CONT changes. Are you suggesting developers that output like
> this be fixed?
Joe has already posted a patch
http://lkml.kernel.org/r/c7df37c866513465
Hello.
I noticed that current linux.git generates hardly readable console output
due to KERN_CONT changes. Are you suggesting developers that output like
this be fixed?
[ 93.723582] Mem-Info:
[ 93.725919] active_anon:380970 inactive_anon:2098 isolated_anon:0
[ 93.725919] active_file:242 in
34 matches
Mail list logo
