linux-kernel - Re: Kernel traces coming back with trash/clutter

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.0.98.0704241944270.26721@sigma.j-a-k-j.com>
Date:	Tue, 24 Apr 2007 19:49:30 -0400 (EDT)
From:	"John Anthony Kazos Jr." <jakj@...-k-j.com>
To:	Mark Hull-Richter <mhullrich@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Kernel traces coming back with trash/clutter

> I am experimenting with the kernel (CentOSv4.4 x86_64, 2.6.9-42.0.10)
> and I have added a number of traces in some relatively sensitive code
> in the page cache and some i/o functions.
> 
> I am getting this odd content in the trace log (dmesg), and I cannot
> figure out what it is or why it is there.
> 
> 4296757675 pdflush(80): do_writepages: map>ops>wrtpgs ffffffffa0195ff5
> 4296757675 pdflush(80): mpage_writepages w/b index 49728 pages 256000
> <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7>
> <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7>
> <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7>
> <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7>
> <7><7><7><7><7>__bio_add_page: 2x ph 88>=128 || hw 88>=88 || 360448>max
> ffffffff802525d8 generic_make_request(bio 000001017c745300) 50729472, 704
> __make_request(q 00000101b9293870, bio 000001017c745300: sdc; 50729600, 704)
> ll_new_hw_segment: 70 + 29 > 88
> <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7>
> <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7>
> <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7>
> <7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7><7>
> <7><7><7><7>__bio_add_page: 2x ph 88>=128 || hw 88>=88 || 360448>max
> ffffffff802525d8 generic_make_request(bio 000001017c745a80) 50730176, 704
> __make_request(q 00000101b9293870, bio 000001017c745a80: sdc; 50730304, 704)
> 4296757684 swapper(0): dl_mv2dsp: sdc start 50710368 secs 1408
> 
> (The lines with the <7>s in them are long - I wrapped them for ease of
> reading and to keep the width down somewhat.)
> 
> Any feedback that might illuminate this would be welcome.  Please CC
> me personally as I am not yet able to subscribe to this list
> (apologies).

"<7>" is KERN_DEBUG in <include/linux/kernel.h>, used with printk. Are you 
using printk in the following forms?

printk(KERN_DEBUG "A debug message.\n");

...or...

const char msg_debug[] = KERN_DEBUG "A debug message.\n";
printk(msg_debug);

Perhaps you have something looping that's outputting KERN_DEBUG with a 
null message? Or one of your diagnostic printk statements includes 
KERN_DEBUG with no actual message?

Remember, if you have a string in a variable without a KERN_* 
prependation, you can do this.

printk(KERN_DEBUG "%s\n", debug_message);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/