lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Sep 2017 18:39:05 +0900 From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> To: pierre kuo <vichy.kuo@...il.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Petr Mladek <pmladek@...e.com>, Sergey Senozhatsky <sergey.senozhatsky@...il.com>, rostedt@...dmis.org, linux-kernel@...r.kernel.org Subject: Re: [RFC V2] printk: add warning while drop partial text in msg Hi, On (09/12/17 14:07), pierre kuo wrote: [..] > int per_cpu_thread_fn(void* data) > { > unsigned int index = 0; > unsigned int len = 0; > char* local_string = kzalloc(2048, GFP_KERNEL); > > do { > len += sprintf((local_string + len), "this is the %d line\n", index++); > }while(len < 576); > printk_deferred("%s", local_string); > return 0; > } which is not a real world example, isn't it? printk_deferred("%s", local_string[2048]) makes no sense anyway, since we limit the message size to 1024 - HEADER chars in vprintk_emit() // see static char textbuf[LOG_LINE_MAX]. I'm not quite following what were you trying to prove, sorry. does any function in the upstream kernel printk()-s buffers larger than LOG_LINE_MAX? which one? - the longest line in my dmesg output is 260 bytes in total (including timestamp) - the second longest is 237 bytes (including timestamp) - the third largest is 191 bytes (including timestamp) the longest single printk() line known to me is from OOM code: show_node(zone); printk(KERN_CONT "%s" " free:%lukB" " min:%lukB" " low:%lukB" " high:%lukB" " active_anon:%lukB" " inactive_anon:%lukB" " active_file:%lukB" " inactive_file:%lukB" " unevictable:%lukB" " writepending:%lukB" " present:%lukB" " managed:%lukB" " mlocked:%lukB" " kernel_stack:%lukB" " pagetables:%lukB" " bounce:%lukB" " free_pcp:%lukB" " local_pcp:%ukB" " free_cma:%lukB" "\n", zone->name, K(zone_page_state(zone, NR_FREE_PAGES)), K(min_wmark_pages(zone)), K(low_wmark_pages(zone)), K(high_wmark_pages(zone)), K(zone_page_state(zone, NR_ZONE_ACTIVE_ANON)), K(zone_page_state(zone, NR_ZONE_INACTIVE_ANON)), K(zone_page_state(zone, NR_ZONE_ACTIVE_FILE)), K(zone_page_state(zone, NR_ZONE_INACTIVE_FILE)), K(zone_page_state(zone, NR_ZONE_UNEVICTABLE)), K(zone_page_state(zone, NR_ZONE_WRITE_PENDING)), K(zone->present_pages), K(zone->managed_pages), K(zone_page_state(zone, NR_MLOCK)), zone_page_state(zone, NR_KERNEL_STACK_KB), K(zone_page_state(zone, NR_PAGETABLE)), K(zone_page_state(zone, NR_BOUNCE)), K(free_pcp), K(this_cpu_read(zone->pageset->pcp.count)), K(zone_page_state(zone, NR_FREE_CMA_PAGES))); but I believe even this line should be less than 1K bytes. or are you aware of any cases when it passes the 1k limit? we are straggling to resolve the _existing_ printk issues, so _theoretical_ and never seen problems are not on my radar. -ss
Powered by blists - more mailing lists