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: <20081021234728.6853beee@lxorguk.ukuu.org.uk>
Date:	Tue, 21 Oct 2008 23:47:28 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jason Wessel <jason.wessel@...driver.com>
Cc:	kgdb-bugreport@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	Jason Wessel <jason.wessel@...driver.com>
Subject: Re: [PATCH 5/7] kgdboc, tty: use tty open to start low level
 drivers

On Tue, 21 Oct 2008 14:14:51 -0500
Jason Wessel <jason.wessel@...driver.com> wrote:

> This patch adds two new hooks to the tty layer in tty_io.c to allow

Gak

> A few minor changes were needed in tty_io.c to deal with the fact that
> the inode and fpath.dentry were NULL with the generic flip structure.

Gak and more gak

> +		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);

Digging deep into tty innards (some of which btw are going to change)

> +		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.

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.

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.

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