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: <20170308053337.GA6776@jagdpanzerIV.localdomain>
Date:   Wed, 8 Mar 2017 14:33:37 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Aleksey Makarov <amakarov.linux@...il.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Aleksey Makarov <aleksey.makarov@...aro.org>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        Sudeep Holla <sudeep.holla@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Peter Hurley <peter@...leysoftware.com>,
        Jiri Slaby <jslaby@...e.com>,
        Robin Murphy <robin.murphy@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        "Nair, Jayachandran" <Jayachandran.Nair@...ium.com>,
        Petr Mladek <pmladek@...e.com>
Subject: Re: [PATCH v3 3/3] printk: fix double printing with earlycon

Hello,

sorry for the delay.

On (03/07/17 15:54), Aleksey Makarov wrote:
> On 03/06/2017 03:59 PM, Sergey Senozhatsky wrote:
> > On (03/03/17 18:49), Aleksey Makarov wrote:
> > [..]
> > > +static enum { CONSOLE_MATCH, CONSOLE_MATCH_RETURN, CONSOLE_MATCH_NEXT }
> > > +match_console(struct console *newcon, struct console_cmdline *c)
> > 
> > that enum in function return is interesting :)
> > can we make it less hackish?
> We probably can, but I can not figure out how to do that.
> Suggestions will be appreciated.
> We should signal 3 different outcomes.
> I thought that using standard errnos is not quite desciptive.

no problems with the enum on its own. errnos probably can also do
the trick.

the way it's defined, however, is a bit unusual and may be
inconvenient - we can add, say, 5 more CONSOLE_MATCH_FOO someday
in the future and match_console() function definition thus will be:

static enum { CONSOLE_MATCH, CONSOLE_MATCH_RETURN, CONSOLE_MATCH_NEXT,
		CONSOLE_MATCH_FOO1, CONSOLE_MATCH_FOO2,
		CONSOLE_MATCH_FOO3, CONSOLE_MATCH_FOO4,
		CONSOLE_MATCH_FOO5}
match_console(struct console *newcon, struct console_cmdline *c)
{
	...
}

or something like this

static enum { CONSOLE_MATCH,
	CONSOLE_MATCH_RETURN,
	CONSOLE_MATCH_NEXT,
	CONSOLE_MATCH_FOO1,
	CONSOLE_MATCH_FOO2,
	CONSOLE_MATCH_FOO3,
	CONSOLE_MATCH_FOO4,
	CONSOLE_MATCH_FOO5 }
match_console(struct console *newcon, struct console_cmdline *c)
{
	..
}

or anything else. which is, to my admittedly imperfect taste, slightly
"unpretty".

[..]
> > > +	/*
> > >  	 *	See if this console matches one we selected on
> > >  	 *	the command line.
> > >  	 */
> > >  	for (i = 0, c = console_cmdline;
> > >  	     i < MAX_CMDLINECONSOLES && c->name[0];
> > >  	     i++, c++) {
> > > -		if (!newcon->match ||
> > > -		    newcon->match(newcon, c->name, c->index, c->options) != 0) {
> > > -			/* default matching */
> > > -			BUILD_BUG_ON(sizeof(c->name) != sizeof(newcon->name));
> > > -			if (strcmp(c->name, newcon->name) != 0)
> > > -				continue;
> > > -			if (newcon->index >= 0 &&
> > > -			    newcon->index != c->index)
> > > -				continue;
> > > -			if (newcon->index < 0)
> > > -				newcon->index = c->index;
> > > -
> > > -			if (_braille_register_console(newcon, c))
> > > -				return;
> > > 
> > > -			if (newcon->setup &&
> > > -			    newcon->setup(newcon, c->options) != 0)
> > > -				break;
> > > -		}
> > > +		if (preferred_console == i)
> > > +			continue;
> > > 
> > > -		newcon->flags |= CON_ENABLED;
> > > -		if (i == preferred_console) {
> > > -			newcon->flags |= CON_CONSDEV;
> > > -			has_preferred = true;
> > > +		switch (match_console(newcon, c)) {
> > > +		case CONSOLE_MATCH:
> > > +			goto match;
> > > +		case CONSOLE_MATCH_RETURN:
> > > +			return;
> > > +		default:
> > > +			break;
> > 
> > sorry, it was a rather long for me today. need to look more at this.
> > for what is now CONSOLE_MATCH_NEXT we used to have continue,
> 
> CONSOLE_MATCH is for the case when the console matches against the description,
> CONSOLE_MATCH_NEXT - it does not, we should try next,

my bad, sorry. I misread the patch: there was another `break' right after
that switch, that you have removed; and I just wrongly concluded that
CONSOLE_MATCH_NEXT would now 'break' from 'default' label *and* `break'
from the console_cmdline loop right after it.

bikeshedding:
may be explicit CONSOLE_MATCH_NEXT test will save us from problems (in
case if match_console() will return more codes someday), may be it won't.
hard to say. 'default: continue' is probably OK. or may be can do without
that 'match' label at all. something like this (_may be_)

	for (i = 0, c = console_cmdline; ... ) {
		if (preferred_console == i)
			continue;

		match = match_console(newcon, c);
		if (match == CONSOLE_MATCH_NEXT)
			continue;
		if (match == CONSOLE_MATCH_FOUND)
			break;
		if (match == CONSOLE_MATCH_STOP)
			return;
	}
	...



CONSOLE_MATCH_RETURN  -  basically means that we should stop matching.
can we thus rename it to CONSOLE_MATCH_STOP, or similar?

	match_console() returned CONSOLE_MATCH_STOP

is a bit better than

	match_console() returned CONSOLE_MATCH_RETURN.

isn't it? :)


// I also used CONSOLE_MATCH_FOUND in the example above instead of
// CONSOLE_MATCH. not insisting that CONSOLE_MATCH_FOUND is much
// better than CONSOLE_MATCH though.

	-ss

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ