linux-kernel - Re: [PATCH v2] printk: Fix preferred console selection with multiple matches

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: <20200106051508.GA17351@google.com>
Date:   Mon, 6 Jan 2020 14:15:08 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2] printk: Fix preferred console selection with multiple
 matches

On (19/12/20 10:11), Petr Mladek wrote:
[..]
> > > > +enum con_match {
> > > > +	con_matched,
> > > > +	con_matched_preferred,
> > > > +	con_braille,
> > > > +	con_failed,
> > > > +	con_no_match,
> > > > +};
> > > 
> > > Please, replace this with int, where:
> > > 
> > >    + con_matched -> 0
> > >    + con_matched_preferred -> 0 and make "has_preferred" global variable
> > >    + con_braile -> 0		later check for CON_BRL flag
> > >    + con_failed -> -EFAULT
> > >    + con_no_match -> -ENOENT
> > 
> > Not fan of using -EFAULT here, it's a detail since it's rather kernel
> > internal, but I'd rather use -ENXIO for no match and -EIO for failed
> > (or pass the original error code up if any). That said it's really bike
> > shed painting at this point :-)
> 
> Sigh, either variant is somehow confusing.
> 
> I think that -ENOENT is a bit better than -EIO. It is abbreviation of
> "No entry or No entity" which quite fits here. Also the device might
> exist but it is not used when not requested.

Can we please keep the enum? Enum is super self-descriptive, can't
get any better. Any other alternative - be it -EFAULT or -EIO or
-ENOENT - would force one to always look at what is actually going
on in try_match_new_console() and what particular errno means. None
of those errnos fit, they make things cryptic. IMHO.

	-ss