linux-kernel - Re: [PATCH 8/8] printk: Add config option for disabling printk offloading

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: <20140423133544.5598c18a@alan.etchedpixels.co.uk>
Date:	Wed, 23 Apr 2014 13:35:44 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Jan Kara <jack@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, pmladek@...e.cz,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 8/8] printk: Add config option for disabling printk
 offloading

> > It's not worth adding for upstream anyway - not in that form. If it just
> > used schedule_work it would be way way cleaner anyway.
>   Alan, please stop complaining that the patches don't use schedule_work()
> when you didn't bother to answer to me when I was explaining to you twice
> what is the problem with using schedule_work().

I have not seen any response to the schedule_work() comment. If the
filters ate it then I apologize.

> console. Plus for useful softlockup reports or oops messages you need also
> the KERN_NOTICE and KERN_INFO messages - stack traces, cpu numbers, process
> information - all this is printed with these levels.

If there is softlockup and oops trace data being printed at KERN_INFO
that could be fixed by changing the level.

> These obvious places could be changed to print with lower log level I
> assume but still I'm somewhat worried that some KERN_INFO messages that
> would be useful for debugging a crash won't make it to console before the
> crash happens.

That's true whatever you do. Either your output is synchronous and makes
it out because it is physically output before the box is permitted to go
bang, or its asynchronous in which case be it work queue, thread or
anything else it may not get out.

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