linux-kernel - Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to platform devices

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]

Date:	Tue, 24 Jul 2007 15:07:04 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Sébastien Dugué 
	<sebastien.dugue@...l.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: commit 7e92b4fc34 - x86, serial: convert legacy COM ports to
 platform devices - broke my serial console

Andrew Morton wrote:
> Well I queued up a tentative revert patch but then I re-read the changlog:
> 
>     x86, serial: convert legacy COM ports to platform devices
>     
>     Make x86 COM ports into platform devices and don't probe for them
>     if we have PNP.
>     
>     This prevents double discovery, where a device was found both by
>     the legacy probe and by 8250_pnp, e.g.,
>     
>         serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>         00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

If this actually causes a problem, then the drivers are buggy.  We have 
standard APIs for checking this stuff...

Turning off legacy serial probing is just a bandaid, the resource bug is 
still there [by definition, if double-probing problems exist].


>     This also means IRDA devices without a UART PNP ID will no longer be
>     claimed by the serial driver, which might require changes in IRDA
>     drivers and administration.

This was completely unaddressed, I presume?


>     In addition to this patch, you may need to configure a setserial init
>     script, e.g., /etc/init.d/setserial, so it doesn't poke legacy UART
>     stuff back in.  On Debian, "dpkg-reconfigure setserial" with the "kernel"
>     option does this.

So this patch breaks some userspace too?


>     To force the old legacy probe behavior even when we have PNPBIOS or
>     ACPI, load the new legacy_serial module (or build 8250 static) with
>     the "legacy_serial.force" option.
> 
> So 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26 fixed a bunch of longstanding
> nasties while breaking Sebastien's machine (at least).
> 
> We of course want the best of both worlds here, so I'll keep the revert
> patch in -mm for a while, see what happens.  Although I can't immediately
> see any way in which this can be fixed...

I see VERY few positives, a whole lot of trouble, and a couple band-aids.

	Jeff


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