lkml.org 
[lkml]   [2012]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: cosmetic printk() issue with lockdep warning in arch/x86/kernel/alternative.c

(Cc:-ed a more interested folks and lkml, as this really matters
to more people than just me)

* Kay Sievers <kay@vrfy.org> wrote:

> mind moving "fixing up alternatives" in:
> arch/x86/kernel/alternative.c:431
> down to where really happens something, or whatever other solution
> fits, maybe it can be removed today ...
>
> The CPU code in:
> arch/x86/kernel/smpboot.c:654
> tries to print continuation lines, which look weird with the
> prefix-less lockdep warning that gets merged into the former line when
> lockdep is enabled:
>
> [ 0.053070] lockdep: fixing up alternatives.
> [ 0.054003] Booting Node 0, Processors #1lockdep: fixing up alternatives.
> [ 0.128995] #2lockdep: fixing up alternatives.
> [ 0.203985] #3lockdep: fixing up alternatives.
> [ 0.278972] #4lockdep: fixing up alternatives.
> [ 0.353960] #5lockdep: fixing up alternatives.
> [ 0.427948] #6lockdep: fixing up alternatives.
> [ 0.501937] #7 Ok.
> [ 0.575952] Brought up 8 CPUs

We could certainly change the lockdep printouts - but I'm really
not sure it's wise to fight those kinds of printk() usage
patterns:

Piecemail wise printouts are handy and natural as they follow
actual code flow. As the code progresses so do the continued
printk()s get progressed. We use single-line printouts to not
use up too much screen real estate during bootup.

So ... why not do what I suggested very, very early on: don't
touch printk screen output itself *AT ALL* - keep it simple and
direct, don't add complexity to the pathway of kernel code
trying to communicate a kernel bug to the user.

Instead solve your needs by simply tracing printk() calls and
the resulting strings [with a string event - I think Steve
posted an RFC patch for that early on - apply that patch and
recover the events - we could build-in this portion of tracing
whenever CONFIG_PRINTK is enabled to make sure the facility is
always available] and reconstruct the lines and the full
ASCII-string events in user-space: if PID,CPU is traced and
there's one record per printk() call then it's *trivial* to
reconstruct 99.9% of the printk lines in the user-space code
that receives the trace events.

Keep /proc/kmsg and don't change it much - but trace printk()
calls form your new systemd code. WHY don't you use that
approach? It's actually totally sensible, useful, it keeps the
printk status quo in place, improves other usecases and can be
done using existing facilities...

Thanks,

Ingo


\
 
 \ /
  Last update: 2012-06-27 08:41    [W:0.051 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site