linux-kernel - Re: [PATCH] 8250: option 'force

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: <87mvl1hahu.fsf@x220.int.ebiederm.org>
Date:	Thu, 28 Jul 2016 13:40:29 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Max Staudt <mstaudt@...e.de>
Cc:	Theodore Ts'o <tytso@....edu>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

Max Staudt <mstaudt@...e.de> writes:

> On 07/27/2016 03:33 PM, Theodore Ts'o wrote:
>
>> I wonder if it would just be simpler to make it be a CONFIG option
>> which causes the irq value to zero in arch/x86/include/asm/serial.h?
>
> Alan hit the nail on the head in his reply to your email: I can't set the IRQ in
> the system configuration. The other option is to compile a custom kernel for this
> system, but that's exactly what I'd like to avoid.
>
> My motivation for this patch is to have a boot time option that allows *any*
> kernel to boot on this broken hardware. This allows for console boot on a broken
> machine even when the machine has never been used in serial console mode before,
> and thus the hardware bug has not been discovered before either.

*Scratches my head*

There is already generic handling for this (that triggers polling) in
the irq code if an irq is screaming.  I am assuming the problem is that
your irq never fires?

Serial consoles are already polled for output.  So nothing should
care until userspace starts, and the full serial driver initializes.

Hmm.

The irq code already has handling for some of these situations,
and if that handling is not sufficient I suspect we could pretty
easily extend it for this case.

For irqs that are screaming we disable them and then poll them.
There there are the "irqfixup" and "irqpoll" command line options
that when an irq is received the code tries all of the irq handlers.

So I suspect either "irqfixup" or "irqpoll" would handle this for you.
If not I am certain a small tweak to some of that code would work.

That should be enough to get a system booted for debugging purposes,
which is the point here.  At which point you can dig in figure out what
is wrong and get the problem design fixed.

Eric