linux-kernel - Re: [PATCH 5/7] kgdboc, tty: use tty open to start low level drivers

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: <48FE87CF.4040007@windriver.com>
Date:	Tue, 21 Oct 2008 20:54:23 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	kgdb-bugreport@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] kgdboc, tty: use tty open to start low level drivers

Alan Cox wrote:
> On Tue, 21 Oct 2008 14:14:51 -0500
> Jason Wessel <jason.wessel@...driver.com> wrote:
>
>> +        unlock_kernel();
>> +    } else {
>> +        tty = tty_driver_lookup_tty(driver, NULL, tty_line);
>> +        if (!tty) {
>> +            tty = tty_init_dev(driver, tty_line, 0);
>> +            inc_tty = 0;
>> +        }
>> +        (*filp)->private_data = tty;
>> +        ret = tty->ops->open(tty, *filp);
>
> and with the error paths wrong
>
>
> This is to put it bluntly just horrible.
>

Yeah, I'd say it is pretty horrible too, but this the only API that
exists presently and it is not at all obvious how to use it.

I am fine with keeping it out of the tree, IE this patch is dropped
from merge consideration for now.  It is obvious that it is a moving
target because the patch to 2.6.27 looked different than 2.6.28.  Even
with it out of the tree I am interested in fixing the "error paths"
you mentioned.  Perhaps in this case the return of tty_init_dev()
needed further checking and that was what you were stating is incorrect?

> Really kgdb, console and other boot processes need an abstraction for tty
> device ports at the device (not ldisc) level and until that work is done
> there is no acceptable way to sort this out. Merging gunk like this will
> simply make the existing mess worse and provide more crap that will make
> it harder to fix properly.

If there is another API, please point me to it.  I am not aware of how
to get uart startup code to run without going through the
tty->ops->open().  The kgdboc module has only a generic high level
interface and makes use of only the high level tty calls.  The
debugger's needs are the same as the console and the user space.  The
early debug is still a special case, but in the ideal world there
would be a way to hand off from early debug into the struct tty_port
at the point that console_init() is called.

>
> All this stuff needs revisiting when every tty device side object in the
> kernel contains a struct tty_port, until then it's a nasty (perhaps
> neccessary for the moment) hack that belongs out of tree.

Let me know when we get closer to that stage, as I am interested in
figuring out how to have a uniform way to share the hardware between
the polled and interrupt drive contexts.

Thanks,
Jason.

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