linux-kernel - Re: [PATCH] powerpc/lpar - defer prefered console setup

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080729073611.GA30627@wavehammer.waldi.eu.org>
Date:	Tue, 29 Jul 2008 09:36:11 +0200
From:	Bastian Blank <waldi@...ian.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	linuxppc-dev@...abs.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powerpc/lpar - defer prefered console setup

On Tue, Jul 29, 2008 at 01:06:18PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
> > Hi
> > 
> > The powerpc lpar code adds a prefered console at a very early state,
> > during arch_setup. This runs even before the console setup from the
> > command line and takes preference.
> > 
> > This patch moves the prefered console setup into an arch_initcall which
> > runs later and allows the specification of the correct console on the
> > command line. The udbg console remains as boot console.
> > 
> Shouldn't it be a console_initcall() ? 

No. console_initcall is for the initial console setup and runs way long
before the command line setup. It needs to run after that.

> > There is a different problem that the code does not pick up the correct
> > console because it uses a part (4) of the lpar device number (30000004)
> > instead of the correct index 1.
> Now, regarding the "different problem" I think it's even worse than
> that, looking at the code there's some non sensical things in here...
> 
> add_preferred_console() argument is what gets compared to
> console->index, right ? Now if you look at hvc_instantiate(),
> it compares each "index" argument passed in to hvc_con_driver.index,
> and that index argument passed from hvc_find_vtys() has strictly
> nothing to do with the vtermno, it's purely the index of the node
> found in order...
> 
> So I think the whole stuff is non-sensical and needs fixing. 

Yep. Would it be a solution to check this in hvc_vio and hvsi and do the
calls there? They now that the device is available and the correct
index. But even then it have to run after the command line. (Or the
console infrastructure fixed to support more then one device of a type.)

Bastian

-- 
Peace was the way.
		-- Kirk, "The City on the Edge of Forever", stardate unknown
--
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/