linux-kernel - Re: amd5536udc interrupts bug

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] [day] [month] [year] [list]

Message-Id: <200901071930.03240.vlobanov@speakeasy.net>
Date:	Wed, 7 Jan 2009 19:30:02 -0800
From:	Vadim Lobanov <vlobanov@...akeasy.net>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	thomas.dahlmann@....com, linux-kernel@...r.kernel.org
Subject: Re: amd5536udc interrupts bug

On Wednesday 07 January 2009 18:32:57 Robert Hancock wrote:
> Vadim Lobanov wrote:
> > The simple fix may be to say that amd5536udc does not support shared
> > irqs, and to remove the IRQF_SHARED flag from the request_irq() call. A
>
> That will bust any other hardware that tries to share the interrupt. If
> a driver requests the interrupt without IRQF_SHARED, nothing else can
> request that interrupt line.

Of course.

And I do still need to check what other bits and pieces of hardware, if any, 
may want to make use of that particular interrupt. Given that I'm trying to 
get this to run on a very specific system (a Hurricane LX-800), the simple 
solution may very well work locally.

In fact, it may even be a good first problem-solving step for the vanilla 
kernel, if only to quickly mark the driver as "known bad with shared irqs" to 
possibly save someone else from having to perform a debugging session. The 
full fix can then happen later.

> > more complicated fix may be to try to shuffle all the code around to
> > make sure that 'dev' is fully initialized before we request the irq, but
> > I don't understand the code well enough (yet) to comfortably do this.
>
> Yeah, that's the proper fix.
>
> > On a side note, it occurs to me that the CONFIG_DEBUG_SHIRQ option
> > went into the kernel a bit less than two years ago, and that it exposes a
> > very immediate and reproducible OOPS in this driver. Does this mean
> > that noone uses the 5536 UDC functionality with any recent kernels?
> > Should I be worried? :)
>
> Presumably nobody uses it with CONFIG_DEBUG_SHIRQ, that option wouldn't
> normally be used on non-debug kernels..

Which does nicely illustrate the value of running a debugging-enabled kernel 
during development. Random OOPSen out in the field == ouch. Much pain was saved 
this time around.

-- Vadim Lobanov

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