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: <06405221-2131-49B4-B3C2-E9773255DC30@mac.com>
Date:	Fri, 21 Sep 2007 18:57:30 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Joe Perches <joe@...ches.com>
Cc:	Rob Landley <rob@...dley.net>, Indan Zupancic <indan@....nu>,
	linux-tiny@...enic.com,
	Michael Opdenacker <michael@...e-electrons.com>,
	CE Linux Developers List <celinux-dev@...e.celinuxforum.org>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Announce] Linux-tiny project revival

On Sep 21, 2007, at 18:05:34, Joe Perches wrote:
> On Fri, 2007-09-21 at 17:34 -0400, Kyle Moffett wrote:
>> With a bit more glue that would cause GCC to notice that for a  
>> given qprintk_kmalloc the "qpk->type" is always zero because the  
>> level is too high, and therefore it would optimize out *ALL* of  
>> the _qprintk_kmalloc(), _qprintk(), and _qprintk_finish() calls.
>
> A negative is that lockup conditions swallow partial messages.

But typically you don't care if a "partial line" gets swallowed  
regardless.  The only reason people really use partial lines is when  
they're accumulating a variable number of things into a single line  
and so a single printk() won't do, and in that case it's really not a  
problem to "lose" the first half of the line in event of a crash.   
And hell, if it matters that much you could just make the qprintk_ 
{kmalloc,percpu,irq} functions chain the qpk variables on a little  
linked list and stuff an smp_wmb() in the _gprint() function after  
writing the text and before writing the size.  That way any panic  
could very carefully look at the messages being queued during the  
crash and attempt to write out partial buffers.

It's a technique which in combination with looking at the first 3  
characters of the arguments to printk() would let you elide 99% of  
the non-critical printks pretty easily while only needing to change  
the much smaller proportion of the printk()s which are partial  
lines.  Furthermore it's pretty easy to grep for the partial-line  
printk()s and you can even have it emit warnings when you hit a  
partial-line printk() (it doesn't start with "<"[0-9]">") in -mm to  
help fix up the last few users and keep people from adding new ones.

Cheers,
Kyle Moffett

-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ