On 30/01/15 12:47, Maciej W. Rozycki wrote:
> On Fri, 30 Jan 2015, James Hogan wrote:
>
>>> Hmm, why can a call to `printk' cause a TLB miss, what's so special about
>>> this function? Does it use kernel mapped addresses for any purpose such
>>> as `vmalloc'?
>>
>> It would be the fact netconsole (or whatever other console is in use) is
>> built as a kernel module, memory for which is allocated from the vmalloc
>> area.
>
> Ah, I see, thanks for enlightening me. But in that case wouldn't it be
> possible to postpone console output from `printk' until it is safe to
> access the device? In a manner similar to how for example we handle calls
> to `printk' made from the hardirq context. That would make things less
> fragile.
Hmm, kernel/printk/printk.c does have:
static inline int can_use_console(unsigned int cpu)
{
return cpu_online(cpu) || have_callable_console();
}
which should prevent it dumping printk buffer to console. CPU shouldn't
be marked online that early, which suggests that the console has the
CON_ANYTIME flag set, which it probably shouldn't if it depends on
module code. call_console_drivers() seems to ensure the CPU is online or
has CON_ANYTIME before calling the console write callback.
A quick glance and I can't see any evidence of netconsole being able to
get CON_ANYTIME.
serial8250_console does appear to set that flag *and* is tristate
though, which is slightly worrying.
Aaro, what is the content of your /proc/consoles?
Cheers
James
Attachment:
signature.asc
Description: OpenPGP digital signature
