Hello Tejun,
On (05/17/16 06:51), Tejun Heo wrote:
> On Tue, May 17, 2016 at 11:42:57PM +0900, Sergey Senozhatsky wrote:
> > > > what if there is no place left for init_utsname() after
> > > > msg_print_ext_header() + msg_print_ext_body()?
> > >
> > > It ends up being truncated, like either of the preceeding calls would.
> >
> > well, I meant once it's truncated your matching doesn't work anymore.
>
> Given that most of the messages are written minding typical console
> widths, whether for editing or outputting, I don't think that's a
> practical concern. We're not talking about appending kilobytes worth
> of additional information here.
hm, I'd probably agree. any chance printk(KERN_CONT) can cause any problems?
for example,
mem_cgroup_print_oom_info():
for_each_mem_cgroup_tree(iter, memcg) {
pr_info("Memory cgroup stats for ");
pr_cont_cgroup_path(iter->css.cgroup);
pr_cont(":");
for (i = 0; i < MEM_CGROUP_STAT_NSTATS; i++) {
if (i == MEM_CGROUP_STAT_SWAP && !do_swap_account)
continue;
pr_cont(" %s:%luKB", mem_cgroup_stat_names[i],
K(mem_cgroup_read_stat(iter, i)));
}
for (i = 0; i < NR_LRU_LISTS; i++)
pr_cont(" %s:%luKB", mem_cgroup_lru_names[i],
K(mem_cgroup_nr_lru_pages(iter, BIT(i))));
pr_cont("\n");
}
there are some other places that do KERN_CONT. e.g. ACPI does KERN_CONT
printk-s from acpi_error/acpi_warning/etc functions. but I've no idea if
there is anything long enough to cause the truncation.
-ss
