linux-kernel - Re: [PATCH] add blockconsole version 1.1

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]

Date:	Tue, 24 Jul 2012 09:01:16 +0100
From:	Tvrtko Ursulin <tvrtko.ursulin@...lan.co.uk>
To:	Jörn Engel <joern@...fs.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Jeff Moyer <jmoyer@...hat.com>,
	Steve Hodgson <steve@...estorage.com>
Subject: Re: [PATCH] add blockconsole version 1.1

On Monday 23 Jul 2012 21:02:30 Jörn Engel wrote:
> On Mon, 23 July 2012 15:33:16 +0100, Tvrtko Ursulin wrote:
> > On Thursday 12 Jul 2012 18:46:34 Jörn Engel wrote:
> > > Console driver similar to netconsole, except it writes to a block
> > > device.  Can be useful in a setup where netconsole, for whatever
> > > reasons, is impractical.
> > 
> > Perhaps you need to add a word or two about limitations compared to
> > netconsole in documentation because it is quite significant difference
> > in reliability? I mean so it is not assumed it is analogous to
> > netconsole but just a different underlying media. I don't know if
> > someone would expect it, but better said than not.
> 
> Given that I don't even know the limitations, that's a bit tough.  As
> a general rule, I would always prefer netconsole.  It appears to be
> more reliable than blockconsole and beats serial console by half a
> lightyear.  But as a fallback when netconsole is not realistic,
> blockconsole has proven useful.

At the very least block console does not work from interrupt context while 
netconsole does, right? Also netconsole does things to try and work around low 
memory situations. Things like that I think would be useful additions to 
documentation.

> > I second the notion that logging to partitions would be useful.
> 
> Below is a compile-tested patch to do that.  Feel free to give it a
> spin and fix any bugs.

I can't promise to do that in the very near future, but in principle idea 
could be interesting to me, at least to evaluate how reliable mechanism is 
with different storage interfaces and controllers.

> > Also, and I haven't checked what the swap format is, if it could somehow
> > be integrated together that could be useful.
> 
> That appears to be slightly less likely than crossbreeding a rabbit
> with a chicken.  Is there something obvious I have missed?

I was thinking how swap space is always there and is potentially much faster 
to write to than a random USB stick - which could translate to more reliable. 
Then it's a question of which storage subsystem (libata vs. usb-storage) would 
work better in different oops/panic situations. Again I tend to have less hope 
in USB based solutions - maybe it's my bias from working in that area many 
years ago. So the idea of swap space was that _if_ swap format could be 
extended to allocate a number of blocks to use other than swap, then that area 
could be used by blockconsole. Seemed like a convenient and potentially more 
reliable solution to me, but as I said the latter may depend.

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